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1.  Introduction 


Chaosnet  is  a  local  network,  that  is,  a  system  for  commimic.iiiou  .imong  a  group  of 
compiilcrs  liKalcd  within  one  or  two  kilomclcrs  of  each  other,  I  lie  name  (  iiaosnet  refers  to  the 
lack  of  any  centralized  control  element  in  this  network. 

Chaosnet  was  originally  developed  in  1975  by  the  Artificial  Iniclligcnce  l  abor.itory  of  die 
Massachusetts  Institute  of  Technology  as  the  internal  communications  mciliuni  of  the  1  isj)  Machine 
system  (ClllNUAI.,  AIM444|.  It  has  since  come  to  he  used  to  link  a  variety  ol  machines  around 
the  Institute.  Chaosnets  also  exist  at  several  other  universities  and  research  l.ihoratories. 

The  l.isp  Machine  system  is  a  multi-processor  in  which  each  active  user  is  assigned  a 
"personal"  computer  consisting  of  a  medium-scale  processor,  a  suitable  amount  of  memory,  and  a 
swapping  disk.  I'ilcs  arc  stored  in  a  central  lilc-systcm  accessed  through  Ch.iosnet.  I  his  shared 
filc-systcm  retains  the  traditional  advantages  of  a  time-sharing  system,  n  iiiiel;  iiitcr-iiser 
communication,  shared  programs,  and  centralized  backup  and  maintenance.  At  the  same  time,  by 
giving  each  active  user  his  own  priKessor,  the  l  isp  Machine  system  is  much  rnor,'  i.ip.ihle  than  a 
time-sharing  system  at  executing  l.isp  programs  several  million  words  in  size  elhnently  and  with 
rapid  interactive  response.  Ilecausc  Chaosnet  is  taking  the  place  of  the  ille  disk  in  .i  conventional 
system,  it  must  be  fast  (both  in  re.sponse  and  in  throughput),  it  must  Ik  leliahle  (tins  is  the 
reason  why  there  is  no  centralized  control),  and  it  must  allow  connection  of  sever.il  dozen 
machines.  However,  it  docs  not  need  to  operate  over  long  distances.  C  h.iosnei  is  useil  to  access 
other  shared  resouices  in  addition  to  llic  file  system;  these  inclinle  prinieis,  i.ipe  diives,  .md  one- 
of-a-kind  specializcil  prcKCssors  and  I/O  devices. 

The  system  goals  for  Chaosnet  were  primarily  simplicity  and  high  perform. nice.  The 
performance  is  achieved  liy  starting  with  a  very  high  speed  transmission  medium  and  oiieniting  it 
in  a  simple,  low-overhead  fashion,  rather  than  by  using  unusually  clever  algm iilinis.  Of  course 
one  has  to  lie  careful  to  avoid  algorithms  which  arc  so  simple  that  they  don't  work  or  w.isie  so 
much  of  the  transmission  medium  that  |)crfurmancc  is  impacted.  Simplicity  was  important  not 
only  to  improve  performance,  hut  because  (.'haosnet  connects  .i  diveise  set  ol  m.khines,  and 
hence  luid  to  h;ive  several  impicmcntiitions  all  of  which  rcqtiirc  niaiiuciiance  in  propnitioii  to  their 
complexity. 

Simplicity  of  design  also  aids  greatly  in  mtiintcnancc  and  management  of  ihe  network  itself, 
which  Inis  proven  to  be  a  non-trivi;il  task  in  a  netwoik  involving  a  variety  of  ni.. chines  ,iiul  usoil 
by  a  variety  of  groups,  even  within  the  single  institution  of  Mi  l.  It  is  important  to  he  ,ihle  to 
isolate  an  apparent  l.iilure  of  the  whole  network  to  tlie  cable  or  to  a  p.iitiLiilai  host's  h.iidwaro  or 
software  ,is  rajiidly  as  possible. 

Ihe  design  uf  (  haosnet  was  greatly  simplilied  by  ignoring,  prohKaits  inelev.int  to  local 
netv.oiks.  (  b  losnet  voiihiins  no  special  provisions  for  things  siicli  as  low  speed  links,  noisy  (very 
big, I)  eiror-rale)  links,  niuliiple  paths,  anil  lung  distance  links  vvitli  snunfii  ,mi  p.msh  time.  Ihis 
nicMiis  111. It  Ch.iosnet  is  not  pailiculailv  snil.ihic  for  use  .h  toss  llu  lonimmi  oi  in  s.ilellite 
.'.('plications,  (  hao'  iii  t  .tlso  makes  no  .iltempt  to  providi-  iinncce  .■>  ii  \  leai'iies  irb  miihiple 
li.'vef,  ol  seivK  c  or  s'  l  me  i oiiimiinic.ilion  (oihei  lb, in  by  end  to  end  eiiriypiinii) 
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Chaosnet  was  largely  inspired  by  the  pioneering  work  on  local  networks  at  Xerox  PARC 
lErHIiRNEl']. 

Chaosnet  consists  of  two  parts— the  hardware  and  the  software— which,  while  logically 
separable,  were  designed  for  each  other.  'Ilic  hardware  provides  a  carrier-sense  multiple-access 
structure  very  similar  to  the  PARC  Ethernet.  Network  nodes  contend  for  access  to  a  cable,  or 
ether,  over  which  they  may  transmit  packets  addressed  to  other  network  nodes.  The  software 
defines  higher-level  protocols  in  terms  of  packets.  I  hcsc  protocols  can  be  (and  arc)  used  with 
media  other  than  die  Chaosnet  cable,  and  with  multiple  interconnected  cables.  The  software 
contains  ideas  borrowed  from  Ethernet  (ETHKRNHTl.  TCP  ffCP],  and  Arpanet,  with  some 
original  ideas  and  modifications. 
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2.  Hardware  Protocol 

2.1  Tlie  Ether 

The  transmission  medium  of  Chaosnet  is  called  the  ether.  Physically  it  is  a  coaxial  cable,  of 
the  semi-rigid  1/2  inch  low-loss  type  used  for  cable  TV,  with  75-ohm  termination  at  botli  ends. 
At  each  network  node  a  aiblc  tninscciver  is  attached  to  the  cable.  A  lO  incicr  Hat  cable  connects 
the  transceiver  to  an  interface  which  is  attached  to  a  compiitci’s  I/O  bus,  A  nciwork  node 
consists  of  this  transceiver  and  interface  and  a  computer  which  executes  a  certain  piece  of  boflware 
called  tlic  Network  Control  Program  (NCP).  which  manages  and  controls  Chaosnet,  in  addition  to 
whatever  application  .software  justifies  its  existence  in  the  first  place. 

One  network  node  at  a  time  may  seize  the  ether  and  transmit  a  packet,  which  arrives  at  all 
other  nodes;  each  node  decides  in  hardware  whether  to  ignore  the  packet  or  to  receive  it.  A 
single  etlier  must  be  a  linear  cable;  it  may  not  contain  branches  nor  stubs,  and  the  ends  may  not 
be  joined  into  a  circle.  The  maximum  length  of  an  ether  cable  is  abotit  1  kilometer.  This  is 

determined  by  dispersion  and  by  DC  attenuation.  The  maximum  number  of  nodes  on  a  single 

ether  is  probably  a  few  dozen.  Ihis  is  determined  by  degradation  of  the  electrical  properties  of 
the  cable  by  the  connectors  used  to  attach  the  transceivers. 

The  maxitnum  length  of  an  ether  could  be  increased  by  using  repeaters  (bidirectional  digital 
amplifiers  joining  two  pieces  of  cable).  In  practice  tliis  is  not  done.  Instead,  the  protocol 

provides  for  multiple  ethers,  joined  together  by  nodes  called  bridges  which  relay  packets  from  one 
ether  to  another.  A  bridge  is  typically  a  pdpll  computer  with  two  or  more  network  interfaces 
attached  to  it.  A  bridge  node  usually  performs  other  tasks  as  well,  such  as  inteiF.icing  terminals. 
Bridges  attach  other  network  media  as  well  as  ethers;  some  compiiters  connect  to  tlic  network 
through  their  manufacturer's  high  speed  computcr-to-computcr  interface  to  a  nearby  hiidgc,  rather 
titan  being  interfaced  directly  to  an  ether.  Asynchronous  lines  have  also  been  used  as  Chaosnet 
media. 

I'hc  form  of  information  on  the  cUicr,  the  transceiver  and  interface  hardware,  and  the 

protocols  which  control  who  may  seize  the  ether  arc  described  in  the  (ollowiiig  sections. 


2.2  Packets 

The  basic  unit  of  transmission  is  called  a  packet.  'I’his  is  a  scqiicntc  of  up  to  40,V2  data  bits, 
plus  48  bits  of  header  information  uscti  by  the  hardware.  Backets  tits  are  noriiially  itK'upcd  into 
16-l)it  words.  I  he  division  of  a  traiisniiUcd  bit  stream  into  packets  provides  a  coiivoiiicnily-.sizcd 
unit  fur  icsouice  alloc.ition  and  error  control.  The  job  of  die  hardware  is  to  deliver  a  packet 
liiiin  one  node  to  another.  Sul'tw.trc  proUK'ols  define  the  meaning  of  the  data  hits  in  a  packet, 
niaiiage  the  h.iidw.irc,  eonipensate  for  iiupciTections  of  the  haidw.irc,  .iiid  |uoviile  more  useful 
services  th.iii  simple  transmission  of  packets  rn>m  one  computer  to  another. 

The  hardwaie  he.idcr  consists  of  three  16-bit  words,  called  dcsiinaliini,  source,  and  check. 
The  source  ideiiiilies  the  node  which  transinilled  this  packet  onto  this  cilier  Ibis  is  not 
nccessaiily  the  oiiruial  soiure  of  tlie  niess.i.e.e.  since  it  lu.iy  have  oriein.iled  on  a  tiill'eicnt  ether. 
I  lie  (le-.iin.ilioM  ideiililii s  the  node  wlii.  It  is  intended  to  receive  this  packet  (umi  this  ciher.  This 
is  not  neces'  aiily  the  (in.il  dcsiiiiatioii  of  the  mess.ige;  it  iiiav  be  .i  bridt'O  whii  h  should  lelay  the 
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packet  to  another  ether,  whence  it  will  eventually  reach  its  final  destination.  Ilic  check  word  is  a 
cyclic  redundancy  checksum,  generated  and  checked  by  hardware,  which  detects  errors  in 
transmission  through  the  ether,  entirely-spurious  packets  created  by  noise  on  the  cable,  and 
memory  errors  in  tlic  transmitting  and  receiving  packet  butfers. 

llie  software  protocol  is  also  based  on  packets,  taking  128  of  the  data  bits  as  a  software 
header.  This  is  described  in  section  3.5,  page  12. 

2.3  The  Transceiver 

Everyone  who  connects  to  the  ether  does  so  through  a  transceiver,  whicli  is  a  small  box 
which  mounts  directly  on  the  cable  via  a  UHF  connector  and  a  f-joint.  All  nodes  use  identical 
transceivers  (the  interface  varies  depending  on  what  computer  it  is  designed  to  interface  to).  ITie 
transceiver  contains  the  analog  portion  of  the  interface  logic,  provides  ground  isolation  between 
the  ether  cable  and  the  computer,  and  contains  some  protective  circuitry  designed  to  prevent  a 
malfimctioning  program  or  interface  from  continuously  jamming  the  ether.  (If  it  were  to  be 
redesigned,  it  ought  to  contain  even  more  protective  circuitry,  since  there  arc  some  possible 
interface  failures  that  can  get  past  the  protection  and  render  the  ether  unusable.) 

The  transceiver  receives  a  differential  digital  signal  from  tlic  computer  interface  and  impresses 
it  onto  the  cable  as  a  level  of  about  8  volts  for  a  1,  or  0  volts  (open  circuit)  for  a  0,  through  a 
very  fast  VMOS  power  FIT.  When  the  cable  is  idle  it  is  held  at  0  volLs  by  the  terminations. 
Iliis  simple-minded  unipolar  scheme  is  adequate  for  the  medium  cable  lengths  and  transmission 
speeds  we  arc  using.  The  transceiver  monitors  the  cable  by  comparing  it  against  a  reference 
voltage,  and  returns  a  differential  signal  to  the  interface.  In  addition,  it  detects  interference 
(another  transceiver  transmitting  at  the  same  time  as  this  one)  and  informs  the  interface. 

The  transceiver  includes  indicators  (light-emitting  diodes)  for  power  OK.  transmitted  data, 

received  data,  and  interface  attempting  to  jam  the  ether.  A  test  button  simulates  an  input  of 

continuous  I’s  from  the  interface,  which  should  light  all  the  lights  (dimly)  if  the  transceiver  is 
working.  These  indicators  and  the  test  button  are  useful  for  rapidly  tracking  down  network 
problems,  'fhc  transceiver  requires  its  own  power  supply  mounted  nearby;  one  power  supply  can 
scr\  ice  three  transceivers  if  tlicy  arc  all  adjacent.  Iligh-voltagc  isolation  between  the  cable  and  the 
computer  is  provided  by  optical  isolators  within  the  transceiver. 

2.4  Tlie  Interface 

'ITic  interface  is  typically  a  wire-wrap  board  containing  about  120  Tl'l,  logic  chips,  which 

plugs  into  the  I/O  bus  of  a  ctimpiitcr  and  cctnnccts  it  to  the  ether  (thiough  a  transceiver.)  'fhc 

interlace  iinpleiiienis  the  hardware  protocols  described  in  the  ncxi  section,  biilfers  incoming  and 
outgoing  (jackets,  generate,  and  rliecks  checksums,  and  interrupts  tlic  liost  comiuitcr  when  a 
packet  is  lo  be  read  out  of  the  receive  packet  hulfcr  or  stored  into  the  iraiisinil  packet  buffer. 
Ihcse  packet  hiiflers  shield  the  host  cominitei  from  the  high  speed  of  data  transmission  on  tlie 
table.  liNe.id  of  having  lo  (jioduce  biLs  at  a  high  rale,  the  host  can  produce  (hem  at  a  lower 
rate,  collect  them  into  a  packet,  and  then  tcii  the  inlcrface  lo  tr.insmit  the  packet  in  a  single 
Inirst  of  hii’.h-s|ioe(l  tr.nismi 'sion. 
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Interfaces  currently  exist  for  Lisp  machines,  for  DKC  l.Sl-11  micro-computers,  and  for  the 
DHC  Unibus  [UNIHUSJ,  which  allows  Chaosnet  to  be  attached  to  pdpll’s,  VAX’s,  and  the 
peripheral  processors  of  most  pdplO’s.  Programming  documentation  for  this  compatible  family  of 
interfaces  appears  later  in  tliis  paper. 

Interfaces  for  other  computers  are  likely  to  exist  in  the  hiture.  'I'he  existing  interface  design 
docs  not  make  any  unusual  special  demands  of  its  host  computer  and  should  be  easily  adaptable 
to  other  architectures. 

2.5  Hardware  Protocols 

The  purpose  of  these  protocols  is  to  deliver  packets  intact  from  one  node  to  anotlier  node  on 
the  same  ctlicr,  with  fairly  high  probability  of  success,  and  to  guarantee  to  give  an  error 
indication  or  lose  the  packet  entirely  if  it  is  not  delivered  intact.  An  additional  puiposc  is  to 
provide  high  perfonnance  and  not  to  bog  down  when  subjected  to  a  heavy  load. 

Bits  are  represented  on  the  ether  using  a  technique  which  is  called  Upright  Biphase  NRZI. 
Each  bit  cell,  which  is  approximately  250  nanoseconds  long,  begins  with  a  transition  in  state, 
from  high  to  low  or  from  low  to  high.  This  traasition  marks  lire  beginning  of  a  bit  cell  and 
provides  self-clocking.  3/4  of  the  way  tlirough  the  bit  cell,  the  state  of  the  cable  is  sampled; 
high  represents  a  1  and  low  represents  a  0.  If  the  bit  being  represented  is  the  same  as  the 
previous  bit,  there  will  be  one  transition  at  the  beginning  of  the  bit  cell  and  a  second  in  the 
middle  of  the  bit  cell.  If  the  bit  being  represented  is  the  opposite  of  the  previous  bit,  there  will 
be  no  transition  in  die  middle  of  the  bit  cell  since  the  clock  transition  will  have  set  the  cable  to 
the  desired  state.  The  AC  frequency  of  die  signal  on  die  cable  varies  between  1/2  die  bit  rate 
and  the  full  bit  rate.  I'lic  information  bit-rate  is  4  million  bits  per  second. 

I'hc  self-clocking  feature  allows  for  slight  variations  in  transmission  and  cable  propagation 
speed.  However,  since  die  3/4  of  a  bit  cell  delay  is  a  fixed  delay,  only  modest  variations  in 
speed  can  be  tolerated.  A  crystal  clock  is  used  as  die  source  of  die  transmit  timing  in  die 
interface. 

Since  there  is  always  at  least  one  state-transition  per  bit  cell,  the  states  where  die  ether 
remains  high  or  low  for  an  appreciable  lime  arc  available  for  non-data  uses.  If  the  ether  remains 
low  for  more  than  about  two  bit  cells,  it  is  considered  to  be  not-busy.  This  condition  marks  die 
end  of  a  packet  and  .illows  someone  else  to  transmit.  Note  that  if  no  transceivers  arc  .ictivc,  the 
terminations  will  hold  the  ether  low. 

If  the  ether  remains  high  for  about  two  bit  cells,  this  is  an  "abort  signal".  .Abort  signals  are 
used  for  two  purposes.  If  the  transceiver  detects  a  collision  (two  nodes  trying  to  Ir.uismit  at  die 
same  lime),  each  transmitting  interface  ceases  to  transmit  and  sends  an  abort  signal  (four  bit  cells 
long),  which  tells  .ill  receivers  to  ignore  the  aborted  packet  and  ensures  that  the  oihei  tiansmittcr 
.also  ahoits.  Thus  when  a  collision  oeeiirs.  the  ether  is  cleaivil  ,is  soon  .is  possible  to  help  prevent 
long  (ie  iips  under  conditions  of  heavy  |o,id.  I  he  oilier  use  for  the  abort  sign.il  is  iii  h.irilwarc 
llow  eoiilrol.  When  ,i  icceiviiig  interlaie  determines  dial  an  incoming,  packet  is  .uldiissed  to  it, 
hut  its  receive  hulfer  alre.idv  eontains  a  packet,  it  sends  an  aliori  signal  whsh  causes  titc 
li,ni', miller  to  stop.  I  his  'cives  the  dual  pnipo-.e  of  immedi.ilelj  inldrming  the  it, man  iiei  ih.it  its 
mes'are  did  iml  get  llnoiigh,  .md  prev.iilmg  the  etlkr  I'roni  henig  tied  up  while  a  Ion'',  p.icket  is 
ir.m.mitted  which  the  receiver  cannot  receive. 
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Packets  arc  transmitted  over  the  ether  in  reverse  bit-order,  for  hardware  convenience.  The 
three  header  words,  which  to  the  software  appear  to  be  at  the  end  of  the  packet,  arc  transmitted 
first  in  the  order  check,  source,  desdnation.  The  data  words,  in  reverse  order,  follow.  Words 
are  transmitted  least-significant  bit  first  Of  course,  the  software  need  not  be  aware  of  this 
reversal;  packets  arrive  at  the  destination  in  the  same  form  as  they  were  created  by  tlic  source. 
At  the  end  of  the  packet  an  extra  zero  bit  is  appended  to  bring  die  ether  to  the  low  state  so 
that  an  extra  spurious  clock-transition  will  not  be  generated  when  it  goes  idle.  This  bit  is  stripped 
off  by  the  interface  and  is  never  seen  by  software. 

The  check  word  is  used  for  error  detection,  as  described  above.  The  source  word  is  made 
available  to  tlic  software,  which  ignores  it  in  most  cases,  and  also  serves  to  synchronize  the  clocks 
in  the  collision-avoidance  mechanism  which  is  described  below.  The  destination  word  is  compared 
by  each  receiver  against  its  own  address.  If  they  match,  or  if  the  destination  is  zero,  or  if  the 
software  selects  the  "match  any  destination"  mode,  die  packet  is  placed  in  the  receive  packet 
buffer  and  the  host  computer  is  interrupted.  The  zero  destination  feature  is  used  for  "broadcast" 
messages.  Note  that  a  receiver  whose  packet  buffer  is  full  will  only  generate  an  abort  signal  if  the 
packet  was  specifically  addressed  to  it. 

2.6  Ether  Contention 

Chaosnet  has  no  centralized  control  element;  when  a  network  node  has  a  message  to  transmit, 
its  interface  seizes  the  ether  and  transmits  a  packet.  Ihc  time  when  it  seizes  die  ether  is 
determined  only  by  state  inside  that  particular  interface  and  by  the  liKal  suite  of  die  cable  at  the 
point  where  that  interface’s  transceiver  is  attached. 

If  two  interfaces  should  decide  to  seize  the  ether  and  transmit  at  the  same  time,  their 
transmissions  will  interfere  and  no  useful  information  will  be  transmitted.  This  is  called  a 
collision.  Collisions  arc  the  principal  limiution  on  the  bandwidth  of  a  heavily-loaded  ether-type 
network,  and  should  be  avoided.  (However,  neidier  PARC's  network  nor  MIT's  network  has  yet 
been  operated  with  a  heavy  enough  load  to  make  collisions  really  significant.) 

(Thaosnet  uses  a  novel  collision  avoid.mce  technique.  I'irst  of  all,  an  interface  will  never 
initiate  transmis.sion  unless  the  ether  is  seen  to  he  not  busy,  i.c.  it  has  been  in  die  low  state  for 
some  time.  I'his  ensures  that  collisions  can  only  (Kcur  near  the  beginning  of  a  packet.  Once 

transmission  of  a  packet  has  gotten  well  started,  the  ether  is  effectively  "seized"  (all  interfaces 

realize  that  it  is  busy)  and  transmission  will  continue  successfully  through  to  die  end  of  the 
packet.  'I  he  amount  of  cdier  transmission  time  wasted  by  a  collided  packet  is  therefore  limited  to 
the  round-trip  cable  propagation  delay.  'Ibis  technique  is  railed  conier  sense. 

Secondly,  the  hardware  uses  a  time-division  tcchnir|uc  to  attempt  to  prevent  two  intci faces 

finm  initi.iting  tr,insmis>ion  at  the  same  lime.  Ibis  technique  sliould  picweiit  essentially  all 

collisions  while  imposing  only  a  modest  delay  in  the  initiation  of  transmission.  It  is  designed  so 
th.it  it  works  better  as  the  load  on  the  eiher  inereascs;  the  wasted  lime  belween  p<i(  kets  and  Ibe 
rel.itive  latc  of  collisions  liolh  decrease. 

I'hc  b.isic  idea  is  lb.it  ear  h  interface  is  assigned  a  bine  -lot.  or  mm.  .iccordiiiL',  to  ils  adrlrcss. 
It  m.iy  only  initiate  ti.iiisimssion  dniing  if  turn.  Hie  linir:  are  sp.i,  eil  f.ir  ciioiii'li  .ip.iil  th.il  if 
one  interl.ice  imtiale-.  Ir.iiisniission.  e'.eiy  oiber  inleihice  will  perceive  ih.n  llic  eihei  >.  busy  bv  die 
lime  Its  own  turn  .niives,  ,iik1  will  not  initiate  .ni  inieirciin;.;  irair mission  I'.uh  inn  il.ne  contains 
,1  lime  slot  i.ounici  which  mnnis  while  the  elhei  is  not  busy,  keeping  back  ol  whose  turn  it  is. 
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Each  packet  synchronizes  the  counters  in  all  of  tlic  interfaces  by  setting  them  from  the  source 
address  of  tliat  packet;  at  the  time  the  packet  was  transmitted,  it  must  have  i'cen  the  turn  of  the 
interface  that  transmitted  it. 

Another  way  to  think  of  this  is  to  make  an  analogy  with  ring  networks.  One  can  imagine  a 
virtual  token  which  passes  down  the  cable  until  it  gets  to  the  end,  tlicn  jumps  to  the  I'Cginning  of 
the  cable  and  repeats.  An  interface  may  only  initiate  transmission  at  the  instant  the  token  passes 
by  it.  When  an  interface  transmits,  the  token  stops  moving  and  remains  at  tJiat  interface  until  the 
end  of  the  packet,  whereupon  it  continues  down  the  cable,  passing  every  other  interface,  giving 
tliem  each  a  chance  to  transmit  before  letting  the  first  interface  transmit  a  second  packet. 

The  token  is  not  represented  by  any  physical  transmission  on  the  cable.  'Hiat  would  constitute 
a  form  of  centralized  control,  and  would  lead  to  reliability  problems  if  the  token  was  lost  or 
duplicated.  Instead,  every  interface  contains  a  time-slot  counter  which  keeps  track  of  where  the 
token  is  thought  to  be.  Every  time  a  packet  is  transmitted  these  counters  arc  brought  up-to-date. 
The  token  cannot  be  lost  because  a  counter  by  its  nature  eventually  returns  to  all  previous  states. 
It  does  not  matter  if  the  token  is  duplicated  (i.c.  the  counters  lose  synchronization)  occasionally, 
since  this  will  only  cause  collisions,  which  we  know  how  to  detect  and  deal  with,  and  since  the 
first  successful  transmission  will  resynchronize  all  counters.  'I'hc  basic  mechanism  of  the  ether 
network  with  contention  and  collisions  is  known  to  work,  and  the  collision-avoidance  scheme  is  an 
added-on  optimization  which  improves  performance  without  changing  the  basic  mechanism. 

There  is  a  finite  propagation  delay  time  between  interfaces,  and  this  time  is  not  small 
compared  with  the  bit-rate  of  Chaosnet,  nor  when  compared  with  the  desirable  length  of  a  time 
slot.  This  time  consists  of  the  delay  in  the  cable,  about  5  nanoseconds  per  meter,  and  the  delay 
through  the  two  transceivers,  about  220  nanoseconds.  This  prop-tgation  delay  moans  th.u  the  time¬ 
slot  counters  in  two  different  interfaces  cannot  be  exactly  synchronized,  and  dial  when  interface  A 
initiates  transmission  interface  R  will  not  instantaneously  sec  that  die  edier  is  busy.  Special 

relativity  tells  us  that  in  fact  the  concept  "exactly  synchronized"  is  nic.tninglcss.  Since  dic  two 

time-slot  counters  arc  not  in  die  same  place,  the  only  way  we  can  compare  them  is  to  send  a 

message  from  one  to  the  other,  through  die  ether,  containing  the  reading  of  the  counter.  Rut  this 
mcs.sagc  takes  non-zero  time  to  get  there,  so  the  coimtcr-rcading  it  contains  is  wrong  by  the  time 
it  is  compared  against  the  other  counter!  We  in  fact  do  send  messages  containing  counter 
readings;  die  source  address  in  a  packet  equals  the  reading  of  the  time-slot  rouiiter  in  the 

interface  diat  sent  it“-;it  the  time  it  was  sent.  Since  die  network  nodes  are  not  in  iel,iti\e  motion, 
we  can  measure  the  distance  between  them  and  use  that  infonn.iiion  to  imiirove  their 
syncluonization. 

What  we  arc  trying  to  do  is  to  prevent  collisions.  This  ii.miis  tli.it  if  inleilace  A  starts 
transmitting  a  ptiekct  in  its  turn,  then  by  the  time  interface  R  thinks  that  its  o\mi  turn  has  arrived, 
it  must  perceive  the  ether  as  busy.  We  will  assign  addresses  (.iiid  hence  time  slots)  .ind  set  the 
length  of  a  lime  slot  in  such  a  way  th.it  tliis  will  happen.  Suppose  the  maxiinnni  del.i>  ihrougli 
the  ether  between  A  and  R  is  t.  This  would  be  the  del, ay  for  one  of  iheni  seiuliii!',  a  packet  to 
the  other;  the  del.i>  heiwecii  A’s  receipt  of  a  third  party's  p.ickel  and  li's  receipt  cl  di.il  pticket  is 
less,  espcciallv  if  the  third  p;uty  is  belw-een  A  aiul  li  on  tlie  eahle,  I  hen  the  ni.iximmii  perceived 
rlitlercnce  I'Civ. een  a  elnck  .it  and  a  clock  at  R  is  ?i:  it  ,i  mess. ice  is  scin  in 'in  It  to  A 
s\  nchroni/iii'.’.  the  clucks,  .nid  then  .i  mess.ipe  is  sent  from  A  Ic  It  ci ini.iinine  \''<  clc,  k  re. iding,  .it 
It  this  ridi  k  iVadlllc  will  ha  stow  bv  .’/. 
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When  a  packet  transmitted  by  A  arrives  at  B,  B‘s  cl(x:k  may  read  as  much  as  2i  earlier  or 

later  than  A’s  turn,  depending  on  the  transmission  direction  of  the  last  synchronizing  message.  In 

order  to  guarantee  tliat  IVs  turn  has  not  yet  happened,  the  time  between  any  of  A's  turns  and 

any  of  IVs  turns  must  always  be  at  least  2l,  twice  die  maximum  propagation  delay  through  the 

ether  between  A  and  B.  This  is  the  important  idea!  We  cause  this  to  be  true  by  assigning 
addresses  starting  at  one  end  of  the  cable;  each  node’s  address  is  the  previous  node’s  address  plus 
twice  the  propagation  delay  between  them,  divided  by  the  length  of  a  turn.  It  is  easy  to  see  that 
if  this  is  done  for  all  adjacent  pairs,  die  condition  will  automatically  be  true  for  non-adjacent 
pairs  as  well.  When  we  get  to  die  end  of  the  cable,  we  must  assign  a  number  of  empty  slots 
equal  to  twice  the  propagation  delay  of  the  full  length  of  cable,  to  provide  the  necessary 
separation  between  the  turns  of  the  two  nodes  at  the  ends  of  the  cable. 

The  virtual  token  travels  through  the  network  at  a  substantially  slower  speed  than  a  real  signal 
such  as  a  packet;  in  the  fastest  case,  when  nodes  arc  very  far  apart,  it  travels  at  just  half  the 
speed  of  a  real  signal.  Since  a  Chaosnet  ether  has  the  geometry  of  a  line,  as  compared  to  the 
ring  net’s  circle,  the  virtual  token  is  also  slowed  down  by  the  need  to  return  from  the  end  of  the 
cable  to  die  beginning.  Ibis  slower  speed  of  the  token  is  die  price  one  pays  for  the  increased 
robustness  of  Chaosnet  as  compared  with  a  ring  network.  In  a  real  system,  we  slow  the  token 
down  even  more  to  provide  a  margin  of  safety.  The  speed  of  the  network  is  not  significantly 
afifected  by  die  slow  token,  since  the  interval  between  packet  transmissions  by  a  single  node  is 
much  longer  than  the  round-trip  time  of  the  token.  Indeed,  if  the  network  is  being  used 
primarily  for  file  transfer,  and  hence  the  packets  arc  large,  the  transmission  time  alone  for  a 
typical  packet  is  several  times  the  round-trip  time  of  the  token.  A  typical  value  for  the  token’s 
round-trip  dmc  is  64  microseconds. 

In  spite  of  all  this,  sometimes  collisions  will  occur  anyway.  If  the  cable  has  been  idle  for  a 
long  time,  the  various  clocks  will  have  lost  synchronization.  If  a  source  address  is  cornipted  by  a 
tr.tnsmission  error,  any  interface  that  sees  that  source  address  will  set  its  cltK'k  to  an  incorrect 
value.  Sometimes  a  packet  will  collide  with  random  noise  rather  dian  another  legitimate  packet. 
In  addition,  the  transmitter  docs  not  distinguish  receiver-busy  aborts  from  real  collisions. 

When  a  collision  docs  occur,  we  recover  from  it  (in  software)  by  retransmitting  the  packet 
again  a  couple  of  times,  hoping  that  we  will  be  lucky  enough  not  to  have  another  collision,  or 
that  the  receiver  will  soon  clear  its  packet  buffer.  This  rctransmi.ssion  is  done  by  the  software,  not 
the  hardware,  since  the  hardware  destroys  die  packet  in  its  packet  bufl'cr  in  tbc  pitKcss  of 
tr.msmitting  it.  Hut  if  collisions  continue  to  occur,  we  give  up  and  let  somebody  else  have  the 
ether.  I  he  packet  is  lost.  A  higher  level  of  protocol  will  soon  rca!i/e  that  it  has  been  lost  and 
letr.uismit  it.  We  assume  that  there  is  enough  rarulomness  in  the  highci-lexel  software  that  the 
two  nodes  which  originally  collided  will  not  collide  again  on  the  retransmission  by  deciding  to 
retransmit  at  precisely  the  same  instant. 
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Software  I’rotocol— World  View 


3.  Software  Protocol-World  View 

'I'tie  purpose  of  tlic  basic  software  proUKol  of  Chaosnet  is  to  allow  high-speed  coiiiiiiunication 
among  processes  on  dilTcrcnt  machines,  with  no  undetected  transmission  errors.  I  he  speed  for  file 
transfers  in  real-life  circumstances  was  to  be  comparable  with  an  inexpensive  magnetic  tape  drive 
(30000  characters  per  second,  or  about  10  times  the  speed  of  the  Aipanct).  We  actually  get  about 
double  tliis  in  some  favorable  cases.  To  achieve  this  speed  it  was  important  to  design  out 
huttlcnccks  such  as  .uc  found  in  the  Arpanet,  for  instance  tlie  control-link  which  is  shared 
between  multiple  connections  and  the  need  to  acknowledge  each  mc.s.sjge  before  the  next  message 
can  be  sent  I'hc  protocol  must  be  simple,  for  the  sake  of  reliability  and  to  allow  its  use  by 
modest  computer  systems.  A  full  Chaosnet  Network  Control  Program  is  just  about  half  the  size 
of  an  Arpanet  NCP  on  the  same  machine,  and  the  protwol  allows  low-perfonnance 
implcmentauons  to  omit  some  features.  .\  minimal  implementation  exists  for  a  single-chip 
microcomputer. 


3.1  Connections 

Tire  principal  service  provided  by  Chaosnet  is  a  connection  between  two  user  processes.  This 
is  a  full-duplex  reliable  paeket-transmission  channel.  The  network  undertakes  never  to  garble, 
lose,  duplicate,  or  resequence  tlic  packets;  in  the  event  of  a  serious  error  it  may  break  the 
connection  olT  entirely,  informing  both  user  proces.scs.  User  programs  may  ciihcr  deal  in  terms  of 
packets,  or  ignore  packet  boundaries  and  treat  the  connection  as  two  uni-direciional  streams  of  8- 
bit  or  16-bit  bytes. 

On  top  of  the  connection  facility  "user"  programs  build  other  ftteilitics,  such  as  file  access, 
interactive  terminal  connections,  and  data  in  other  byte  sizes,  such  as  36  bits.  I'hc  meaning  of 
the  packets  or  bytes  transmitted  through  a  connection  is  defined  by  the  particular  higher-level 
protocol  in  use. 

In  addition  to  rcli.iblc  communication,  the  protocol  provides  flow  control,  includes  a  way  by 
which  prospective  communicants  may  get  in  touch  with  each  other  (called  contacting  or 
nndezvous),  and  provides  various  network  maintenance  and  lvjusckee|)ing  facilities.  I  hose  are 
discussed  later. 


3.2  Contact  Names 

When  first  esuihlishing  a  connection,  it  is  necessary  for  the  i\o  communicating  prrx'esscs  to 
contact  each  other.  In  addition,  in  the  usual  user/server  situ.iiion,  the  server  piiteess  docs  not 
exist  befoichand  and  needs  to  be  created  and  made  to  execute  the  .ippropriale  piogr.im. 

Wc  eho'.c  to  implement  eontaeting  in  an  asymmetric  way.  (t)nee  the  eonnei  lion  Has  been 
esUihlishcil  everything  is  ci'inpletely  symmetiie.)  One  pri'cess  is  desi.enated  the  nvr.  and  the  other 
is  designated  the  v/ivv.  fhe  server  has  some  contact  name  to  which  it  !i\icn\.  1  he  iisei  jnoccss 
requests  its  loi.il  oper.iting  system  to  connect  it  to  the  sener.  speiilying  the  nelwoif  node  and 
coin  Id  name  ol  the  server.  The  local  operating  system  sends  a  me-.'.ige  (,i  /.’e,/;,,  x/  for 

(  niiiinii.m)  to  tlu  emote  npei.iting  system,  which  examines  the  contad  name  ,nul  eic.ites  .i 
coiineeiioii  to  ,1  lislemitg  pioeess.  eie.iies  .i  mw  seiver  piocess  and  connects  to  it  oi  rejis  Is  the 
lequest. 
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Automatically  discovering  to  which  host  to  connect  in  order  to  obtain  a  particular  service  is  a 
subject  for  higher-level  protiKols  and  for  further  research.  It  is  not  dealt  with  by  Chaosnet. 

Once  a  connection  has  been  estiiblishcd.  there  is  no  more  need  for  the  contact  name  and  it  is 
discarded.  Indeed,  ollen  the  contact  name  is  simply  the  name  of  a  service  (stich  as  "TELNET") 
and  several  users  should  be  able  to  have  simultaneous  connections  to  separate  instances  of  that 
service,  so  contact  names  must  be  reusable. 

In  the  ease  where  two  existing  processes  that  already  know  about  each  other  want  to  establish 
a  connection,  we  arbitrarily  designate  one  as  the  listener  (server)  and  the  other  as  the  requester 
(user).  'I'he  listener  somehow  generates  a  "unique"  contact  name,  somehow  communicates  it  to 
the  requester,  and  listens  for  it.  'I'he  requester  requests  to  connect  to  that  contact  name  and  the 
connection  is  established.  In  the  most  common  case  of  establishing  a  second  connection  between 
two  prix-'csses  which  are  already  connected,  the  index  number  (see  below)  of  the  first  connection 
can  serve  as  a  unique  contact  name. 

Contact  names  arc  restricted  to  strings  of  upper-ease  letters,  numbers,  and  ASCII  punctuation. 
The  maximum  length  of  a  contact  name  is  limited  only  by  the  packet  si/e,  altliough  on  IT'S  hosts 
the  names  of  automatically-started  servers  arc  limited  by  tlic  file-system  to  six  characters. 

See  page  21  for  complete  details  of  how  to  establish  a  connection. 

3.3  Addresses  and  Indices 

l’.iich  node  (or  host)  on  the  network  is  identified  by  an  adilrm,  which  is  a  16-bit  number. 
'I'liesc  addresses  arc  used  in  the  routing  of  packets.  There  is  a  table  (the  system  hosts  table, 
SYoRIN;H0STS2,  in  the  case  of  IT'S)  which  relates  symbolic  host  names  to  numeric  host 
addresses. 

An  address  consists  of  two  fields.  'The  most-significant  8  bits  identify  a  subnet,  and  the  least- 
signific.mt  8  bits  identify  a  host  within  that  subnet.  Both  fields  must  be  non-zcio.  A  subnet 
torivsi^onds  to  a  single  transmission  path.  Some  subnets  are  physical  Chaosnet  cables  (ethers), 
while  others  are  other  media,  for  instance  an  interface  between  a  pdplO  and  a  pdpll.  'The 
sigiiilicancc  of  subnets  will  become  clear  when  routing  is  discussed  (see  section  3.7,  page  13). 

Wlicii  a  host  is  connected  to  an  ether,  the  host's  hardware  .address  on  that  ether  is  the  same 
as  its  soliw.tie  address,  including  the  subnet  field. 

A  KMinec  lion  is  s|H'ci(ied  by  the  names  of  its  two  enils.  Such  a  name  consists  of  a  IfiTiit  host 
acLIicss  .Iiid  a  Ifi-hit  connection  index,  which  is  assigned  b>  that  host,  as  the  n.inie  of  the  entity 
nrade  the  lio.t  which  owns  tlie  connection.  The  only  lequircments  pi. iced  li\  llu'  pioiocid  on 
iiuliccs  .lie  th.il  they  he  non  /ero  .iiui  Ih.it  they  be  unique  wilhin  a  paiticiil.n  ho,i;  ih.ii  is,  .i  host 
m.iy  not  .i  .  i.ni  the  same  index  number  to  two  dillereiii  i  oniieciioiis  mile'.-,  cnon  h  lime  h.is 
I  lap' ed  luiwei'ii  ihe  clo'diig  of  the  liisl  eonneclion  .nid  the  opening  of  the  s.-.oiid  connection  lh.it 
conliision  beiwecn  llie  tv.o  is  unlikely. 


I  pie,, If.  (he  Ic.c 
.  .!>  le  ,  I  I'l,  .liid  1 
"  pi"  1  ;c  ineii'i  lu  '■ 
,,!  ,i  f '■  h  I  "cn,. 


'  f  nilic  inl  n  bits  ol  an  inde',  .ni-  o  ed  .i-.  .i  M'lio  iipi  n  to  die  opei  iiini' 
c  III,  !■  1  '  H  If ,  Mil  In  ;i  hie,  ,1.  ;•  II,,  I ,  HI.  nil  it  "  I,  h  l"o.  .1  I  f  f  •  |, ,,  ,  , ,  i|  ,  f 
Ih''  imnifei  ol  I|IC||||0III  Ini  .mi  '  ■  aliiienil,  I  ,  ,,  ii,|mi,  1  I"  Ihe 

•'lllifle  sfil,  ,I|  ■  liiie.f  dill  ll  I  ..  .  . . .  li,'.  iP.'  .mi.  Iiiil.'.  ,| 
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packet  from  the  old  connection  cannot  sit  around  in  the  network  (c.g.  in  biifl'crs  inside  liosts  or 
bridges)  long  enough  to  be  seen  as  belonging  to  the  new  connection. 

It  is  important  to  note  tliat  packets  arc  nol  sent  betv  '•cn  hosts  (physical  computers).  I'hcy  arc 
sent  between  user  processes;  more  exactly,  between  channels  aiutchcd  to  user  prcKCsscs.  Each 
channel  has  a  32-bil  identification,  which  is  divided  into  subnet,  host,  index,  and  uniquization 
fields.  From  the  point  of  a  view  of  a  user  process  using  the  network,  die  Network  Control 
Program  section  of  his  host’s  operating  system  is  part  of  die  network,  and  the  multiplexing  and 
demultiplexing  it  performs  is  no  different  from  the  routing  performed  by  other  parts  of  the 
network.  It  makes  no  diflcrcncc  whether  two  communicating  pr(x;esscs  run  in  the  same  host  or  in 
different  hosts. 

Certain  control  packets,  however,  arc  sent  between  hosts  rather  dian  users,  'fliis  is  visible  to 
users  when  opening  a  connection;  a  contact  name  is  only  valid  with  rc.spect  to  a  particular  host. 
'I'his  is  a  compromise  in  the  design  of  Chaosnet,  vvhich  was  made  so  diat  an  operational  system 
could  be  built  without  first  solving  the  research  and  engineering  problems  associated  with  making 
a  diverse  set  of  hosts  into  a  uniform,  one-level  name  space. 

3.4  Packet  Numbers 

There  arc  two  kinds  of  packets,  controlled  and  uncontrolled.  Controlled  packets  arc  subject  to 
error-control  and  flow-control  protocols,  described  below  (see  section  3.8,  page  16),  which 
guarantee  dial  each  controlled  packet  is  delivered  to  its  destination  exactly  once,  that  the 
controlled  packets  belonging  to  a  single  connection  arc  delivered  in  die  same  order  they  were  sent, 
and  diat  a  slow  receiver  is  not  overwhelmed  with  packets  from  a  fast  sender.  Uncontrolled 
packets  arc  simply  transmitted;  they  will  usually  but  not  always  arrive  at  their  destination  exactly 
once.  The  protocol  for  using  diem  must  take  Uiis  into  account. 

Each  controlled  packet  is  identified  by  an  unsigned  16-bit  packet  number.  Successive  packets 
arc  identified  by  sequential  numbers,  with  wrap-around  from  all  I's  to  all  O's.  When  a  connection 
is  first  opened,  each  end  numbers  its  first  controlled  packet  (RFC  or  OEN)  however  it  likes,  and 
that  sets  the  numbering  for  all  following  packets. 

Packet  numbers  should  be  compared  modulo  65536  (2  to  the  16th),  to  ensure  correct  handling 
of  wrap-around  cases.  On  a  pdpll,  use  the  instructions 
CMP  A.B 
BMI  A_is_less 

Do  not  use  the  B(.T  or  BLO  instruction.  On  a  pdpid,  use  the  inst.  ctions 
SUB  A,B 
TUNE  A, 100000 
JHST  A_is_less 

Do  nol  use  the  CAMfli:  instruction.  On  a  l  isp  machine,  use  the  code 
(II  (n [  I  (Esr  //o  100000  (  a  n) ) 

-A  is  1rss>) 

Do  luit  use  the  I  I  !iSI’  (m  <)  function. 
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3.5  Packets 

A  packet  consists  of  a  header,  which  is  8  16-bit  words,  and  zero  or  more  8-bit  or  16-bit  bytes 

of  accompanying  data.  In  addition  there  are  three  words  put  on  by  the  hardware,  described 

earlier  in  this  paper. 

The  following  are  the  8  header  words: 

Operation  The  most-significant  8  bits  of  this  word  arc  the  Opcode  of  the  p.icket,  a 

number  which  tells  what  the  packet  means.  The  128  opcodes  with  high-order 

bit  0  arc  for  the  use  of  the  network  itself.  The  128  opcodes  with  high-order 

bit  1  are  for  use  by  users.  'ITic  various  opcodes  arc  described  in  chapter  4, 
page  20. 

The  least-significant  8  bits  of  this  word  are  reserved  for  future  use,  and  must 
be  zero. 

Count  The  most-significant  4  bits  of  tliis  word  arc  the  forwarding  count,  which  tells 

how  many  times  this  packet  has  been  forwarded  by  bridges.  Its  use  is 
explained  in  the  Routing  section. 

The  least-significant  12  bits  of  this  word  arc  the  data  byte  count,  which  tells 
the  number  of  8-bit  bytes  of  data  in  the  packet.  The  minimum  value  is  0  and 
the  maximum  value  is  488.  Note  tliat  die  count  is  in  8-bit  bytes  even  if  die 
data  arc  regarded  as  16-bit  bytes. 

Destination  Address 

fhis  word  contains  the  network  address  of  die  destination  host  to  which  this 
packet  should  be  sent. 

Destination  Index  This  word  contains  the  connection  index  at  the  destination  host  of  die 
connection  to  which  this  packet  belongs,  or  0  if  this  packet  docs  not  belong  to 
any  connection. 

Source  Address  This  word  contains  the  network  address  of  die  source  host  which  originated  this 
packet. 

Source  Index  'Iliis  word  contains  die  connection  index  at  the  source  host  of  the  connection 
to  which  this  packet  belongs,  or  0  il’  this  packet  does  not  belong  to  any 
connection. 

/‘(icket  Number  If  this  is  a  controlled  packet,  this  word  cont.iins  its  identifying  number. 

Ackiumlcdficmenl  Hie  use  ol  tliis  word  is  described  in  section  ,1.8,  p.igc  16. 
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3.6  Data  Formats 

Data  transmitted  through  Chaosnet  generally  follow  I  isp  Machine  standards.  Hits  and  bytes 
arc  numbered  from  right  to  left,  or  least-significant  to  most-significant,  I  hc  first  8  bit  byte  in  a 
16-bit  word  is  die  one  in  die  arithtneiicaliy  least-significant  position.  I  he  first  16  bit  word  in  a 
32-bit  double-word  is  die  one  in  the  arithmetically  least-significant  position. 

The  character  .set  u.sed  is  dictated  by  the  )iighcr-lcvc)  protixiol  in  use.  Iclnct  and  Supdup,  for 
example,  each  specifies  its  own  ASCll-based  character  set.  The  "default"  character  set— used  for 
new  protocols  and  for  text  that  appears  in  the  basic  Chaosnet  prottKol.  such  as  contact  names — is 
die  l.isp  Machine  ,.liaractcr  set  [ClIINUAl.).  This  is  basically  ASCII,  augmented  with  addidonal 
printing  characters  and  a  different  set  of  format-effector  (or  "control")  characters. 

Because  the  rules  for  bit  numbering  conflict  with  the  native  byte-ordering  in  pdplOs,  and 
because  it  is  quite  expensive  to  rearrange  die  bytes  using  the  pdplO  instruction  set.  pdplls  which 
act  as  front-ends  for  pdplOs  must  reformat  packers  passing  through  them,  and  pdplOs  interfaced 
directly  to  the  network  must  have  interfaces  capable  of  rearranging  the  bytes.  This  requires  that 
die  network  protocols  explicidy  specify  which  portions  of  each  type  of  packet  are  8-bit  bytes  and 
which  arc  16-bit  bytes.  In  general  the  hcdocr  is  16-bit  bytes  and  the  data  field  is  8-bit  bytes,  but 
certain  packet  types  (Ol’N,  SIS,  BUT,  and  opcodes  300  dirough  377)  have  16-bit  bytes  in  die 
data  field.  Use  of  32-bit  data  is  rare,  so  no  provision  is  made  for  putting  .l.Tbit  data  into  the 
standard  format  for  pdplOs.  On  our  current  network  pdplOs  arc  the  only  hosts  which  require  this 
packet  reformatting  assistance,  because  most  modern  computers  number  their  bits  ,ind  bytes  from 
least-significant  to  most-significant. 

The  effect  of  this  is  diat  user  programs  that  use  the  Chaosnet  always  sec  the  data  in  a  packet 
and  its  header  in  the  native  form  of  the  machine  they  arc  running  on.  and  the  necessary 
convcisio  is  arc  automatically  applied  by  the  network.  I'his  statement  applies  to  die  order  of  bits 
and  bytes  within  a  word,  but  not  to  the  character  set  (when  packets  contain  tcxtu.il  data)  which  is 
dictated  by  proUKols. 

Unlike  some  other  network  protocols,  Chaosnet  docs  not  use  any  software  checksumming. 
Because  of  tlic  diversity  of  hosts  with  cliircrcnt  architectures  attached  to  the  Chaosnet,  it  is 
impossible  to  devise  a  checksumming  algorithm  which  can  be  executed  cominitiMy  and  cfliciently 
on  all  hosts.  Instead,  Cliaosnct  relies  on  error-cliecking  hardware  in  the  network  inteif.ices,  and 
assumes  that  other  sources  of  p.icket  damage  that  checksums  could  detect,  such  as  sufiw.ire  bugs 
in  a  Network  Control  Program,  either  do  not  occur  or  wifi  produce  symptoms  so  ohwous  that 
they  will  be  delected  and  fixed  immediately. 


3.7  Koiitin{; 

consists  of  deciding  how  to  deliver  a  packet  to  the  iiciwoik  ihhIc  specified  by  tJic 
destination  address  field  of  the  packet,  I  l.ivini’,  reached  that  node,  the  p.u  kel  i.in  iioially  be 
cleliveied  to  the  destination  user  process  m.i  (lie  desim.iti(>n  index.  In  ecnci.il  uniimp  may  be  a 
niiilii  step  pioccss  iinolving  transmission  tliiou;.'li  scvci.il  subnets,  siiuc  ilu  ic  n  .r,  imi  be  ,i  direct 
birdwaie  cinmccliuii  between  the  somcc  uid  the  dcsiin.iiion.  Note  III. it  Ihc  loniinc  .Kcisicn  is 
iii.idc  s.  pai.itcly  ((If  (.icli  (i.ickct,  '.Mill  III'  fclcicii'c  In  the  <  mu  i  pi  nl  i omn i  1). iie. 
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Any  host  that  is  connected  to  more  than  one  subnet  acts  as  a  bridge  and  forwards  packets 
from  one  subnet  to  another  when  necessary.  ITterc  could  also  be  hardware  bridges  which  are  not 
hosts,  although  we  have  not  yet  designed  any  such  device.  Since  routing  docs  not  depend  on 
connections,  a  bridge  is  a  very  simple  device  (or  program)  which  does  not  need  much  state.  I  his 
makes  the  bridge  function  inexpensive  to  piggyback  onto  a  computer  which  is  also  performing 
other  functions,  and  makes  reliable  bridge  software  easy  to  implement. 

'I  he  difference  between  a  bridge  and  a  gateway,  in  our  terminology,  is  lliat  a  bridge  forwards 
packets  from  one  sub-Chaosnet  to  another,  without  modifying  the  packets  or  undcretanding  them 
other  than  to  look  at  the  destination  address  and  increment  tlic  forwarding  count,  and  docs  not 
deal  with  connections  nor  witli  flow  control,  while  a  gateway  interconnects  two  networks  with 
ditfciing  proUKols  and  must  understand  and  translate  tlie  information  passing  through  it 
Gateways  may  also  have  to  deal  with  flow  and  error  control  because  they  connect  networks  with 
slow  or  differing  speeds,  llridges  are  suitable  for  local  networks  while  gateways  arc  suitable  for 
long-distance  networks  and  for  conneeting  networks  not  produced  by  the  same  organization. 

To  prevent  routing  loops,  each  packet  contains  a  forwarding-count  field.  Hach  bridge  that 
forwards  the  packet  increments  this  count;  if  the  count  reaches  its  maximum  value  the  packet  is 
discarded.  I'he  error-control  protocol  will  recover  discarded  packets,  or  decide  Uiat  no  viable 
connection  can  be  established  between  the  two  hosts. 

The  implementation  of  routing  in  an  operating  system  is  as  follows,  given  a  packet  to  be 
routed,  wliich  may  have  come  in  from  die  network  or  may  have  been  originated  by  the  local 
host.  Tirst,  check  the  packet’s  destination  addrcs.s.  If  it  is  this  host,  receive  the  packet. 
Otherwise,  increment  the  forwarding  count  and  discard  the  packet  if  it  has  been  forwarded  too 
many  times.  If  the  destination  is  some  other  host  on  a  subnet  to  which  this  host  is  directly 
connected,  transmit  the  packet  on  that  subnet;  the  destination  host  should  receive  it.  If  the 
destination  is  a  host  on  a  subnet  of  which  this  host  has  no  knowledge,  look  up  the  subnet  in  the 
host's  routing  table  to  find  the  best  bridge  to  that  subnet,  and  transmit  the  packet  to  tltat  bridge. 

lutch  host  has  a  routing  table,  indexed  by  subnet  number,  which  tells  how  to  get  packets  to 
hosts  on  diat  subnet.  Hiich  entry  contains:  (exact  dctitils  may  vary  depending  on  implementation) 

Type  The  type  of  connection  between  the  host  and  this  subnet.  Phis  can  be  one  of 

Direct,  Bridge,  or  Ti.xed  Bridge.  Direct  means  a  physical  connection  such  as  a 
Chaosnet  interface.  Bridge  means  an  indirect  connection,  via  a  packet- forwarding 
bridge.  Which  bridge  is  best  to  use  is  to  be  disciwcrcd  by  this  routing 
mcih.inism.  I'ixcd  Bridge  is  the  same  except  that  the  automatic  mechanism  is  not 
to  cli.inge  wliich  bridge  is  used.  This  is  useful  to  set  up  cx|)licit  touting  for 
purposes  such  as  network  debugging. 

l,/(/)c,\\  hknlilics  llic  Knmeclion  to  Ihis  subnet  in  a  w.iy  vvliiih  depends  on  llic  type.  I'or 

.1  duel  t  connection,  this  identifies  Ihe  piece  ol'  hardware  whicli  implements  the 
connection.  (It  might  be  a  1  hiibus  address.)  (•'or  a  hiidgc  or  a  fixed  bridge,  this 
IS  Ihe  network  .iddress  of  the  bridge. 

(  lO/  A  me.ismc  of  the  cost  of  sending  a  |i.ickel  tinough  this  louie.  Costs  are  u.sed  to 

select  the  best  route  from  among  allein.ilives  in  a  wav  desciibed  below.  1‘or  a 
dneci  connection,  tin-  kisI  is  III  for  ,i  dneii  inleir.ice  between  two  computers  (eg. 
I’'  le'en  .1  pdpKI  .ilid  its  liolil  eiui  pdpll).  II  loi  ,i  (  ll.Mi.n'l  elhei  c.ilile.  !'ll  lot' 
.1  s'ow  medium  sni  h  .is  in  .is\ m. hroiunis  line,  etc,  l  or  ,i  biidn.e  oi'  a  lived  hiidge, 
iIk  i.i'  i  is  spemiled  b\  the  blidm.'  in  ,i  I'.l  '  1  p n  kel  (desciilied  below). 
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The  routing  Liblc  is  initialized  with  the  number  of  a  more  or  less  arbitrary  existent  Itost  and  a 
high  cost,  for  each  subnet  to  which  the  host  is  not  directly  connected.  Until  the  eonect  bridge  is 
discovered  (which  nonn  illy  happens  within  a  minute  of  coming  up),  packets  for  that  subnet  will 
be  bounced  off  of  that  arbitrary  host,  which  probably  knows  the  right  bridge  to  forward  tliem  to. 

The  cost  for  subnets  accessed  via  bridges  is  increased  by  1  every  4  seconds,  tlius  typically 
doubling  after  a  minute.  When  the  cost  reaches  a  "high”  value,  it  sticks  there,  preventing 
problems  with  .iriihmetic  overllow.  The  purpose  of  tJie  increasing  cost  is  to  discount  the  value  of 
old  information.  The  cost  for  subnets  accessed  via  direct  connections  and  fixed  bridges  docs  not 
increase. 

Every  15  seconds,  a  bridge  advertises  its  presence  by  broadcasting  a  routing  (RUT)  packet  on 
each  subnet  to  which  it  is  directly  connected.  Each  host  on  that  subnet  receives  the  RUT  packet 
and  uses  it  to  update  its  routing  table.  If  die  host’s  routing  table  says  to  access  a  certain  subnet 
via  bridges,  and  tlic  RUT  packet  says  tliat  this  is  the  best  bridge  to  that  subnet,  the  routing  table 
is  updated  to  say  that  this  bridge  should  be  used. 

Note  tliat  it  is  important  that  the  rate  at  which  the  costs  increase  with  time  be  slow  enough 
that  it  takes  more  than  twice  die  broadcast  interval  to  increase  the  cost  of  one  hop  to  be  more 
than  the  cost  of  two  hops.  Otherwise  the  routing  algorithm  is  not  well-behaved.  Suppose  subnet 
A  has  two  bridges  {a  and  /I)  on  it.  and  bridge  o  is  connected  to  subnet  B  but  bridge  (i  is  not  (it 
goes  to  some  other  inclevanl  subnet).  I  hcn  if  the  costs  increase  too  fast  and  bridges  «  and  p  do 
not  broadcast  dicir  RUT  packets  exactly  simultaneously,  sometimes  packets  for  subnet  B  may  be 
sent  to  bridge  fi  because  its  cost  appears  lower.  Bridge  /I  will  then  send  diem  to  bridge  a,  where 
they  should  have  gone  directly.  In  more  complicated  situations  packets  can  go  around  in  a  circle 
some  of  the  time. 

I'hc  source  address  of  a  RU'I'  packet  must  be  dic  hardware  address  of  die  bridge  on  the 
particular  subnet  on  which  die  packet  is  broadcast.  The  destination  address  of  a  RUT  packet 
must  be  zero;  RU'I  packets  arc  not  forw.irdcd  onto  other  subnets.  The  byte  cdunt  of  a  RUT 
packet  is  a  multiple  of  4  and  the  packet  contains  up  to  122  pairs  of  16-bit  words; 

word  I  The  subnet  number  of  a  subnet  which  this  bridge  can  get  to.  directly  or 

indirectly,  rigiit-adjustcd. 

word  2  Ihe  cost  of  sending  to  that  subnet  via  this  bridge.  Hiis  is  the  current  cost  from 

the  bridge’s  routing  table,  plus  the  cost  for  the  subnet  on  which  the  routing 
packet  is  being  broadcast.  Adding  the  subnet  cost  eliminates  loops,  and  prefers 
one-hop  paths  over  two-hop  padis. 

When  a  host  receives  a  RUT  packet,  it  prtK'csscs  each  2-word  entry  hy  comp.iring  the  cost  for 
that  subnet  against  its  current  cost;  if  it  is  less  or  cciual  the  cost  .uid  the  address  of  the  hiidgc 
arc  entered  into  the  routing  table,  provided  that  that  subnet’s  routing  table  entry  is  not  of  the 
Direct  or  f  ixed  Bridge  type. 

When  there  are  multiple  equivalent  bridges,  the  trallic  is  spread  among  them  only  by  virtue 
of  their  RLI'f  packets  being  sent  at  dilierent  times,  so  that  sonictinics  one  lirniee  li.is  ihe  lower 
co.'i,  and  sometimes  the  other.  If  this  isn’t  adeipiate.  hosts  could  ha\c  h.iinci  looiing  l.hles 
which  icmeiiiliei  mote  tli.iii  one  po'-silile  loute  and  use  ihcm  .iccoiding  lo  then  icfilo,.'  i  osts,  but 
•1)  lai  this  li.i',  iiMi  been  I'ces'  ay  since  the  nctwuik  trallic  is  nol  so  lugh  .is  to  s.iiiii  iic  .my  one 
bridj’c. 
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The  design  of  this  routing  scheme  is  predicated  on  the  assumption  that  the  network  geometry 
is  simple,  there  arc  few  multiple  paths,  and  the  length  of  any  path  is  quite  short.  Ihis  makes 
more  sophisticated  schemes  unnecessary. 

An  important  feature  of  this  routing  scheme  is  tliat  the  size  of  the  table  is  proportional -to  the 
number  of  subnets,  not  to  the  number  of  hosts.  Thus  it  does  not  take  up  an  inordinate  amount 
of  memory  in  a  small  computer,  and  no  complicated  dynamic  allocation  schemes  arc  required. 

In  the  case  of  a  pdplO  which  accesses  the  Chaosnet  tluough  a  front-end  pdpll,  we  define  the 
interface  between  the  two  computers  to  be  a  subnet,  and  regard  the  pdpll  as  a  bridge  which 
forwards  packets  between  the  network  and  the  pdplO.  This  gives  tlie  pdplO  and  the  pdpll 
separate  addresses  so  that  we  can  choose  to  talk  to  either  one,  even  though  tlicy  arc  part  of  the 
same  computer  system.  This  is  occasionally  useful  for  maintenance  purposes.  It  becomes  more 
useful  when  the  front-end  pdpll  has  peripherals  which  arc  to  be  accessed  through  the  Chaosnet, 
since  they  can  simply  look  like  hosts  on  that  pdplTs  private  subnet. 

In  the  ease  of  a  host  which  is  attached  to  more  than  one  subnet,  it  is  undesirable  for  the  host 
to  have  more  than  one  address,  since  this  would  complicate  user  programs  which  use  addresses. 
Instead,  one  of  the  host’s  network  attachments  is  designated  as  primary,  and  that  address  is  used 
as  the  host’s  single  address.  The  other  attachments  arc  regarded  as  bridges  which  can  forward  to 
tliat  host.  Sometimes,  we  simplify  the  routing  by  inventing  a  new  subnet  which  contains  only  that 
host  and  has  no  physical  realization.  The  host’s  address  is  an  address  on  that  fake  subnet.  All  of 
the  host’s  network  attachments  arc  regarded  as  bridges  which  know  how  to  forward  packets  to  that 
subnet. 

The  I  TS  host  table  allows  a  host  to  have  multiple  addresses  on  multiple  networks,  but  when 
you  ask  for  the  address  of  a  certain  host  on  a  certain  network  you  only  get  back  the  primary 
address.  All  packets  coming  from  that  host  have  that  as  their  source  address. 

3.8  Flow  and  Error  Control 

The  Network  Control  Programs  (NCPs)  conspire  to  ensure  that  data  packets  arc  sent  from 
user  to  user  with  no  garbling,  duplications,  omi.ssions,  or  changes  of  order.  Secondarily,  the 
NCPs  attempt  to  achieve  a  maximum  rate  of  flow  of  dam,  and  a  minimum  of  overhead  and 
retransmission. 

The  fuiKl.iinenial  basis  of  flow-control  and  error-control  in  Chaosnet  is  rdronsmisskm.  Packets 
which  arc  d.iniagcd  in  tiansiiiissioii,  which  won't  fit  in  biiircr.s,  wliich  arc  du|)liciitcd  or  out-of- 
sei|iicncc,  or  which  otherwise  arc  embarrassing  arc  simply  discarded.  Packets  arc  periodically 
retransmitted  until  an  indication  that  tlicy  have  been  snccessrnlly  rcceiscd  is  relmned.  Ihis 
rctr.insmi-.sioii  is  ciul-lo-end;  any  intermediate  bridges  do  not  pariieipatc  in  llow-contiul  and  error- 
control.  and  hence  .ire  free  to  discard  any  packets  they  wish. 

I  hcre  arc  actually  two  kinds  of  packets,  conirollcil  and  uiwoiilnillrii.  Controlled  packets  arc 
icliansnhited  and  ilclivcrcd  reliably;  most  packets,  including  all  p.ickels  used  by  the  user  (except 
for  I  INC  packets),  arc  of  Ihis  type.  1  Ineonirolled  pai  l;cls  are  not  ivUan  .milled;  ihcse  arc  used 
liii  c’ltaiii  lower  le\el  fimetions  of  the  protocol  such  as  the  inipf'inc'iu  ition  of  (low  and  error 
control.  I  he  usage  of  iluse  paekels  is  designeil  so  that  they  need  noi  In-  rf  liwicd  icliildy. 


nSt.;NUHlN;AMlti  K  107 


l.S  JllN-81 


Chaosnet 


17 


I'low  and  hrror  Control 


Retransmission  of  a  packet  continues  until  stopped  by  a  signal  from  the  receiver  to  [[ic  sender 
called  a  receipt.  A  receipt  contains  a  packet  number,  and  indicates  that  all  controlled  pacivcts  with 
a  packet  number  less  than  or  equal  (modulo  65536)  to  that  number  have  treen  successfully 
received,  and  therefore  need  not  be  retransmitted  any  more.  A  receipt  docs  not  iiulicate  tliat 
these  packets  have  been  processed  by  the  destination  user  process:  it  simply  indicates  that  they 
have  successfully  arrived  in  the  destination  host,  and  arc  guaranteed  to  be  tlicrc  when  the  user 
process  asks  for  them. 

Ihcrc  is  another  signal  from  the  receiver  to  the  sender,  called  an  acknowledgement.  An 
acknowledgement  also  contains  a  packet  number,  and  indicates  that  all  controlled  packets  with  a 
packet  number  less  tlian  or  equal  (modulo  65536)  to  that  number  have  been  read  by  the 
destination  user  process.  This  is  used  to  implement  flow-control.  Note  tliat  acknowledgement  of  a 
packet  implies  receipt  of  that  packet.  In  fact,  if  the  receiving  pnx;css  does  not  fail  behind, 
explicit  receipts  need  not  be  sent,  because  tlic  receiving  host  will  not  have  to  buffer  any  packets, 
but  will  acknowledge  tliem  as  soon  as  they  arrive. 

'fhe  purpose  of  flow-control  is  to  match  the  speeds  of  the  sending  and  receiving  processes, 
'fhe  extremes  to  be  avoided  are,  on  tlie  one  hand,  too  small  a  "buffer  size"  causing  the  data 
transmission  rate  to  be  slower  than  it  could  be,  and  on  the  other  hand,  large  numbers  of  packets 
piling  up  in  the  network  because  the  sender  is  sending  faster  than  the  receiver  is  receiving.  It  is 
also  necessary  to  be  aware  tliat  receipts  and  acknowledgements  must  be  transmitted  through  tlic 
network,  and  hence  have  an  associated  cost. 


Chaosnet  flow-control  operates  by  controlling  the  number  of  packets  "in  the  network".  These 
are  packets  which  have  been  emitted  by  the  sending  user  prtKess,  but  have  not  been 
acknowledged.  We  define  a  window  into  the  set  of  packet  numbers.  The  beginning  of  this 
window  is  the  first  packet  number  which  has  not  been  acknowledged,  and  die  width  of  the 
window  is  a  fixed  number  established  when  the  connection  is  opened.  The  sending  prtKess  is 
only  allowed  to  emit  packets  whose  packet  numbers  lie  within  the  window.  Once  it  has  emitted 
all  of  the  packets  in  the  window,  die  window  is  said  to  be  full.  I’hus,  die  size  of  die  window  is 
the  "buffer  size"  for  die  connection,  and  is  the  maximum  nunibcr  of  packets  that  may  need  to  be 
buffered  inside  an  NCR  (sending  or  receiving).  Acknowledgements  move  die  window,  making  it 
not  full,  and  allowing  the  sending  process  to  emit  additional  packets. 

We  do  not  receipt  and  acknowledge  every  single  controlled  packet  that  is  transmitted  through 
a  connection,  since  tliat  would  double  or  triple  die  number  of  packets  sent  through  the  network 
to  move  a  given  amount  of  data.  Instead  we  batch  the  receipts  and  acknowledgements,  but  if 
acknowledgements  are  not  sent  suflicicnily  often,  the  data  will  not  flow  smoothly,  because  the 
window  will  often  appear  full  to  the  sender  wtien  it  is  not.  If  receipts  are  not  sent  sufliciently 
ollen.  there  will  be  unnecessary  retransmissions. 

Whenever  a  p.ickct  is  sent  through  a  connection,  an  acknowledgement  for  the  rcierse 
direction  of  that  connection  is  "pig.g.y  hai  ked"  onto  it,  using  the  Acknowledgement  lield  in  the 
packet  header,  for  inter.ictive  applic.itions,  where  there  is  much  trallic  m  both  diiet lions,  this 
provides  all  the  necessary  .lekiinwledgeineiii  .ind  receipting  witli  no  nevd  to  send  .my  evlr.i  p.iekets 
through  the  network. 


When  this  does  not  siiHice,  SIS  t-.i.itiis)  p.iekets  ,ire  t'.ener.iied  to  c.iiiv  i  ceiiiis  .nid 
,11  knov.ledgciiK  Ills.  S'lfi  packets  .ne  uii'.-'iiiiolK-d.  since  they  aie  |i,iii  of  the  nn.  h  iiii'.iu  iluit 
implements  conimlled  p.nkels.  It  an  MS  puket  is  dnplu.itv'd.  ii  doc-  im  h.iini.  Il  .in  SI'S 
p.icket  is  lost  inecli.inisms  exist  whiih  mil  cause  a  ivplaccineiu  m  he  ceiiei.ilcd  later  ,\n  SIS 
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packet  carries  separate  receipt  and  acknowledgement  packet  numbers. 

When  a  user  process  reads  a  packet  from  the  network,  if  the  number  of  packets  which  should 
have  been  acknowledged  but  have  not  been  is  more  than  1/3  the  window  size,  an  S'i'S  is 
generated  to  acknowledge  them.  'Fhus  the  preferred  batch  si/c  for  acknowledgement  is  1/3  the 
window  size.  The  advantage  of  this  size  is  that  if  one  SI'S  is  lost,  another  will  be  generated 
before  the  window  fills  up  (at  the  2/3  point). 

When  a  packet  is  received  with  the  same  packet  number  as  one  which  has  already  been 
successfully  received,  this  is  evidence  of  unnecessary  retransmission,  and  an  SI'S  is  generated  to 
carry  a  reccipi  back  to  the  sender.  If  this  STS  is  lost,  the  next  retransmission  will  stimulate 
anotlier  one.  Thus  receipts  arc  normally  implied  by  acknowledgements,  and  only  sent  separately 
when  there  is  evidence  of  unnecessary  retransmission. 

Retransmission  consists  of  sending  all  unreceipted  controlled  packets,  except  those  that  were 
last  sent  very  recently  (within  1/30’th  of  a  second  in  ITS.)  Retransmission  occurs  every  1/2 
second.  'ITiis  interval  is  somewhat  arbitrary,  but  should  be  close  to  the  response  time  of  the 
systems  involved.  Rciran,smi.ssion  also  occurs  in  response  to  an  S'l'S  packet,  so  that  a  receiver 
may  cause  a  faster  rctranmission  rate  titan  twice  a  second  if  it  so  desires,  lliis  should  never  cause 
useless  retransmission,  since  STS  carries  a  receipt,  and  vcry-recently-transmitted  packets,  which 
might  still  be  in  transit  through  the  network,  arc  not  retransmitted. 

Another  operation  is  probing,  which  consists  of  sending  a  SNS  packet,  in  the  hope  of 
eliciting  either  an  STS  or  a  I.OS,  depending  on  whether  the  other  side  believes  the  connection 
exists.  Probing  is  used  periodically  as  a  way  of  testing  that  the  connection  is  still  open,  and  also 
serves  as  a  way  to  get  STS  packets  retransmitted  as  a  hedge  against  the  loss  of  an 
acknowledgement,  which  could  otherwise  stymie  the  connection.  SNS  packets  are  uncontrolled. 

We  probe  every  five  seconds  on  connections  which  have  unacknowledged  packets  outstanding 
(a  non-empty  window)  and  on  connections  which  have  not  received  any  packets  (neither  data  nor 
control)  for  one  minute.  If  a  connection  receives  no  packets  for  1  1/2  minutes,  this  means  that  at 
least  5  probes  have  been  ignored,  and  the  connection  is  declared  to  be  broken:  either  the  remote 
host  is  down  or  there  is  no  viable  patli  through  die  network  between  the  two  hosts. 

The  receiver  can  generate  "spontaneous"  S'TS's,  to  stimulate  retransmission  and  keep  tilings 
moving  on  fast  devices  with  insullicicnt  buffering  for  1/2  second  worth  of  packets.  I'his  provides 
a  w.iy  for  the  receiver  to  speed  up  die  retransmission  timeout  in  the  sender,  and  to  make  sure 
th.it  acknowledges  arc  happening  often  enough. 

Note  th.it  die  network  still  functions  if  either  or  both  parties  to  a  connection  ignore  the 
window.  Ihe  window  is  sinijily  an  iiupiover  of  efliLieuiy.  Receipts  h.oc  the  s.ime  property.  I'his 
allows  very  small  imiilemcntations  to  be  compatible  with  the  same  protocol,  which  is  useful  for 
applications  such  as  bootstrapping  through  the  network. 

It  would  be  possible  to  have  tlynamic  adjuMment  of  the  window'  size  in  response  to  observed 
behavior.  I  lie  SIS  p.ickct  includes  Ihe  window  si/c  so  tli.ii  eh.inees  to  it  c.in  he  coniimmiealcd. 
However,  this  h.is  not  been  found  neees>.nry  in  practice.  I  ach  higher  level  pioioi  ul  h.is  ,i  st.nul.ird 
pie  deteiinnc  il  window  size,  wliirh  it  c  i.ihlishes  when  it  liist  opens  .i  counci  non.  .nid  this  seems 
1(1  he  (  lose  eiioiiph  to  opiimiim  Ih  il  e.nelul  dynanin  .idiuslmeiu  of  it  wouldn't  lU  ike  ,i  hin, 
dilleienee. 
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'I’his  scheme  for  flow-control  and  error-control  is  based  on  several  assumptions.  It  is  assumed 
that  the  underlying  transmission  media  have  their  own  checking,  so  that  they  discard  all  damaged 
packets,  making  packet  checksums  iinncccssi\ry  at  the  protiKol  level.  The  transit  time  flirough  the 
network  is  assumed  to  be  fast,  so  that  a  fairly-small  retransmission  interval  is  practical,  and 
negative  acknowledgements  arc  not  necessary.  The  error  rate  is  assumed  to  be  low  so  tliat  overall 
efficiency  is  not  aflccted  by  the  simple-minded  error  recovery  scheme  of  simply  retransmitting  all 
outstanding  packets.  It  is  assumed  that  no  reformatting  of  packets  occurs  inside  the  network,  so 
that  flow-control  and  error-control  can  operate  on  a  packet  basis  rather  than  a  byte  basis. 
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4.  Software  Protocol-Details 

In  the  following  sections,  each  of  the  packet  Opcodes  and  the  use  of  that  packet  type  in  the 
protocol  is  described.  Opcodes  arc  given  as  an  octal  number,  a  three-letter  code,  and  a  name. 

Unless  otherwise  specified,  the  use  of  the  fields  in  the  packet  header  is  as  follows.  The 
source  and  destination  address  and  index  denote  the  two  ends  of  the  connection;  when  an  end 
docs  not  exist,  as  during  initial  connection  establishment,  that  index  is  zero.  The  opcode,  byte 
count,  and  forwarding  count  fields  have  no  variations.  The  packet  number  field  contains 
sequential  numbers  in  controlled  packets;  in  uncontrolled  packets  it  contains  die  same  number  as 
the  next  controlled  packet  will  contain.  The  acknowledgement  field  contains  the  packet  number  of 
the  last  packet  seen  by  the  user. 

4.1  Connection  Eiitablishnient 

The  following  packet  types  are  associated  with  creating  and  destroying  connections.  First  the 
packets  are  described  and  then  the  details  of  die  various  connection-establishment  protocols  are 
given. 

I  RFC  Request  for  connection 

All  connections  arc  initiated  by  the  transmission  of  an  RFC  from  the  user  to  the  server.  The 
data  field  of  the  packet  contains  the  contact  name.  The  contact  name  can  be  followed  by 
arbitrary  arguments  to  the  server,  delimited  by  a  space  character.  ITic  destination  index  field  of 
an  RFC  contains  0  since  the  destination  index  is  not  known  yet. 

RFC  is  a  controlled  packet;,  it  is  retransmitted  until  some  sort  of  response  is  received. 
Uccause  RFC’s  arc  not  sent  over  normal,  error-controlled  connections,  a  special  way  of  detecting 
and  discarding  duplicates  is  required.  When  an  NCP  receives  an  RFC  packet,  it  checks  all 
pending  RF’C’s  and  all  connections  which  arc  in  die  Open  or  RFC-received  stale  (see  section  4.6, 
page  25),  to  see  if  die  source  address  and  index  match;  if  so,  the  RFC  is  a  duplicate  and  is 
discarded. 

12  LSN  Listen 

A  server  process  informs  the  local  NCP  of  the  contact  name  to  which  it  is  listening  by 
sending  a  I.SN  packet,  with  the  contact  name  in  the  data  field.  This  packet  is  never  transmitted 
anywhere  through  the  network.  It  simply  serves  as  a  ccmvenienl  hull'cr  to  hold  the  server's  contact 
name.  When  an  RFC  and  .i  1.SN  cont.iining  the  same  cont.ict  name  meet,  die  I.SN  is  discarded 
and  die  RFC  is  given  to  the  server,  putting  its  connection  into  die  RFC-received  stale  (see  section 
4.6,  page  25).  I  he  server  reads  the  RFC  and  decides  whether  or  not  to  open  the  connection. 


2  OPN  Open  connection 

OPN  is  the  usual  positive  response  to  RFC.  Fhe  source  index  field  eoiocvs  the  soivci's  index 
numher  to  (lie  user;  the  user's  index  nuinhei  was  coiueved  in  the  RF't  '.  I  he  d.ii.i  held  of  DI’N 
is  the  same  .is  that  of  SIS  (sec  below);  it  servC'.  m.iinl)  to  uonve>  the  server's  window  si/e  to  the 
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user.  The  Acknowledgement  field  of  the  Ol'N  acknowledges  the  RFC  so  that  it  will  no  longer  be 
retransmitted. 

OPN  is  a  controlled  packet;  it  is  retransmitted  until  it  is  acknowledged.  Duplicate  OPN 
packets  arc  detected  in  a  special  way;  if  an  OI^N  is  received  for  a  connection  which  is  not  in  the 

RFC-sent  suite  (sec  section  4.6,  page  25),  it  is  simply  discarded  and  an  SI'S  is  sent.  This  can 

happen  if  the  connection  is  ojicncd  while  a  retransmitted  OPN  packet  is  in  transit  through  the 

network,  or  if  the  SIS  which  acknowledges  an  OPN  is  lost  in  Uie  network. 

3  CLS  Close  connection 

CI.S  is  the  negative  response  to  RFC.  It  indicates  that  no  server  was  listening  to  the  contact 
name,  and  one  couldn’t  he  created,  or  for  some  reason  the  server  didn’t  feel  like  accepting  this 
request  for  a  connection,  or  die  destination  NCP  was  unable  to  complete  tlie  connection  (e.g. 
connection  table  full.) 

CI.S  is  also  used  to  close  a  connection  after  it  has  been  open  for  a  while.  Any  data  packets 
in  transit  may  be  lost.  Protocols  which  require  a  reliable  end-of-data  indication  should  use  the 

mechanism  for  that  (sec  section  4.4,  page  24)  before  sending  CFS. 

The  data  field  of  a  CLS  contains  a  character-string  explanation  of  the  reason  for  closing, 
intended  to  be  returned  to  a  user  as  an  error  message. 

CLS  is  an  uncontrolled  packet,  so  that  the  program  which  sends  it  may  go  away  immediately 
afterwards,  leaving  nothing  to  retransmit  tlie  CLS.  Since  there  is  no  error  recovery  or 
retransmission  mechanism  for  CLS,  the  use  of  CLS  is  necessarily  optional;  a  process  could  simply 
stop  responding  to  its  connection.  However,  it  is  desirable  to  send  a  CLS  when  possible  to 
provide  an  error  message  for  the  user. 

4  FWD  Forward  a  request  For  connection 

This  is  a  response  to  RFC  which  indicates  tliat  the  desired  service  is  not  available  from  the 
process  contacted,  but  may  be  available  at  a  possibly-difFerent  contact  name  at  a  possibly -dilferent 
host.  The  data  field  contains  the  new  contact  name  and  the  Acknowledgement 
field — exceptionally — contains  the  new  host  number.  The  issuer  of  the  RFC  shouUl  issue  another 

RFC  to  that  address.  FWD  is  an  uncontrolled  pticket;  if  it  is  lost  in  the  network,  the 

retransmission  of  the  RFC  will  presumably  stimulate  an  identical  FVVI), 

5  ANS  Answer  to  a  simple  transaction 

riiis  is  anothci  kind  of  response  to  RFC.  1  he  data  field  contains  the  entirety  of  the  response, 
and  no  connection  is  cst.iblishcd.  ANS  is  .m  uncontrolled  packet;  if  it  is  lost  in  the  network,  llic 
rcliviusmi'.'.ion  of  the  lil'l.'  will  pri'siinijhl)  sliunil.it''  an  idciilic.i)  AN.S. 

I  here  arc  sexcral  conuccliun  initi.ition  piutocols  implemented  with  these  pac  ket  types. 

When  an  I’K'  .mius  .it  .i  host.  th.  N(  1'  finds  a  usci  proic.s  licit  is  lislciiin;'  loi  this  RFC's 
coni, 11  1  name,  nr  cre.it^  s  a  priKc.-,  ni  nimidc  ihc  desired  sei\ke.  nr  re'|inads  tn  ilm  RFC 

itseir  if  it  knows  luiw  to  |iio\idc  the  icqiie  ii  d  ".ivse.  oi  u'l'uses  the  iec|uesl  lor  lomieeiion,  I  he 
irnxess  th.il  .cues  the  K1  t_  chooses  vrlm  h  1 1  nnei lion  iniliaiion  pioieeol  to  lollow,  Ihis  process  is 
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given  the  RFC  as  data,  so  that  it  can  look  at  the  conUict  name  and  any  arguments  that  may  be 
present 

A  stream  connection  is  initiated  by  an  l^FC,  transmitted  from  user  to  server.  I'hc  server 
returns  an  OPN  to  the  user,  which  responds  with  an  S  I'S.  I'hcsc  three  packets  convey  the  -source 
and  destination  addresses,  indices,  initial  packet  numbers,  and  window  sizes  between  the  two 
NCR’s.  In  addition  a  character-string  argument  can  be  conveyed  from  the  user  to  the  server  in 
the  RFC. 

The  OPN  serves  to  acknowledge  the  RP'C  and  extinguish  its  retransmission.  It  also  carries  the 
server’s  index,  initial  packet  number,  and  window  size.  'I’hc  SI'S  serves  to  acknowledge  die  OPN 
and  extinguish  its  retransmission.  It  also  carries  the  user’s  window  size;  die  user's  index  and 
iniual  packet  number  were  carried  by  the  RFC.  Retransmission  of  the  RFC  and  the  OPN 
provides  reliability  in  the  face  of  lost  packets.  If  the  RFC  is  lo.st,  it  will  be  retransmitted.  If  the 
S  I’S  is  lost,  the  OPN  will  be  retransmitted.  If  the  OPN  is  lost,  the  RFC  will  be  retransmitted 

superfluously  and  the  OPN  will  be  retransmitted  since  no  S  I’S  will  be  sent. 

'The  exchange  of  an  OPN  and  an  STS  tells  each  side  of  the  connection  that  die  other  side 
believes  the  connection  is  open;  once  this  has  happened  data  may  begin  to  flow  dirough  the 
connection.  The  user  process  may  begin  transmitting  data  when  it  sees  the  OPN.  riie  server 

process  may  begin  transmitting  data  when  it  sees  the  S  I’S.  These  rules  ensure  dial  data  packets 

cannot  arrive  at  a  receiver  before  it  knows  and  agrees  that  the  connection  is  open.  If  data  packets 
did  arrive  before  then,  the  receiver  would  reject  them  with  a  I.OS  (see  below),  believing  them  to 
he  a  violation  of  protocol,  and  this  would  destroy  the  connection  before  it  was  ever  Hilly 
established. 

Once  data  packets  begin  to  flow,  they  arc  subject  to  die  flow  and  error  control  protocol 
described  in  section  3.8,  page  16.  Thus  a  stream  connection  provides  the  desired  reliable, 
bidirectional  data  stream. 

A  re/usa/  is  initiated  by  an  RFC  in  the  same  way,  but  the  server  returns  Cl.S  radicr  than 
OPN.  The  data  field  of  the  Cl,S  contains  die  reason  for  refusal  to  connect. 

A  fonvardrd  connection  is  initiated  by  an  RF’C  in  the  same  way,  but  the  server  returns  a 
1  WO,  telling  die  user  another  place  to  look  for  the  desired  service. 

A  siinide  transaction  is  initiated  by  an  RFC  from  user  to  .server,  and  completed  by  an  ANS 
i'luin  server  to  user.  Since  a  full  connection  is  not  established  and  die  reliable-transmission 
me. hanism  of  conneelions  is  not  useil,  die  user  process  c.ninot  he  sure  how  many  copies  of  the 
Ki  t'  the  ‘'Crver  saw,  .ind  the  server  process  cannot  be  sure  tli.it  its  answer  got  h.iek  to  the  user. 

I  hi',  iiie.ms  th  il  simple  li.iir.'ictimis  .lioiild  not  be  used  lor  applii  .n imis  where  it  is  important  to 
know  whether  the  iraiisaction  was  re.illy  completed,  nor  for  .ipplii  .ilioiis  in  which  repealing  ilic 
s  ime  ipiei  v  mi,!', hi  proilucc  a  dill’erent  answer.  Simple  ii.in'..u  lions  are  a  simple  ellicient 
im'h.im.m  liir  applications  such  as  evlr.icling  ;i  small  piece  of  inforntalion  (e.,e.  die  time  of  day) 
f'loiii  a  cenir.il  ilata  basc. 


I  )M  .MmON  AMId  K  1(1/ 


IS  ,1111/  111 


Chaosnet 


23 


Status 


4.2  Status 

7  STS  Sutus 

STS  is  an  uncontrolled  packet  which  is  used  to  convey  sutus  infonnation  between  NCPs.  ITie 
Acknowledgement  field  in  the  packet  header  contains  an  acknowledgement,  that  is,  the  packet 
number  of  tlic  last  packet  given  to  the  receiving  user  process.  The  first  16-bit  byte  in  the  data 
field  contains  a  receipt,  that  is,  a  packet  luimbcr  such  tliat  all  controlled  packets  up  to  and 
including  tliat  one  have  been  successfully  received  by  the  NCP,  The  second  16-bit  byte  in  the 
data  field  contains  die  window  size  for  packets  sent  in  die  opposite  direction  (to  the  end  of  the 
connection  which  sent  die  ST'S).  The  byte  count  is  presendy  always  4.  This  will  change  if  the 
protocol  is  revised  to  add  additional  items  to  the  ST'S  packet. 

6  SNS  Sense  status 

SNS  is  an  uncontrolled  packet  whose  sole  purpose  is  to  cause  the  other  end  of  the  connection 
to  send  back  an  ST'S.  This  is  used  by  die  probing  mechanism  described  above  (see  page  18). 

11  LOS  I.ossage 

TOS  is  an  uncontrolled  packet  which  is  used  by  one  NCP  to  inform  another  of  an  error.  The 
data  field  contains  a  character-string  explanation  of  die  problem.  T  he  source  and  destination 
addresses  and  indices  arc  simply  the  destination  and  .source  addresses  and  indices,  respectively,  of 
the  erroneous  packet,  and  do  not  necessarily  correspond  to  a  connection.  When  an  NCP  receives 
a  I.OS  whose  destination  corresponds  to  an  existent  connection  and  whose  source  corresponds  to 
die  supposed  other  end  of  that  connection,  it  breaks  die  connection  and  makes  the  data  field  of 
the  I.OS  available  to.  the  user  as  an  error  message.  Other  l.OS’s,  that  don't  correspond  to 
connecdons,  arc  simply  ignored. 

I.OS  is  sent  in  response  to  situations  such  as:  arrival  of  a  data  packet  or  an  SI'S  for  a 
connection  that  docs  not  exist  or  is  not  open,  arrival  of  a  packet  from  die  wrong  source  for  its 
destination,  arrival  of  a  packet  containing  an  undefined  opcode  or  too  large  a  byte  count,  etc. 

l.OS’s  arc  given  to  the  user  process  so  that  it  may  read  the  error  message. 

No  I.OS  is  given  in  response  to  an  OPN  to  a  connection  nut  in  the  Ki''C-Scnt  sUte,  nor  in 
response  to  a  SNS  to  a  connection  not  in  the  Open  state,  nor  in  response  to  a  I  OS  to  a  non¬ 
existent  or  broken  connection,  fhese  rules  arc  important  to  ni.iXc  the  protocols  work  without 
timing  errors.  An  OPN  or  a  SNS  to  a  non-existent  crmnection  elicits  a  I.OS. 
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4.3  Data 

200-277  OAT  8-bit  Date 

Opcodes  200  through  277  (octal)  arc  controlled  piickcts  with  user  data  in  8-bit  bytes  in  the 
data  field.  The  NCP  treats  all  64  of  these  opcodes  identically:  some  higher-level  protocols  use  the 
opcodes  for  their  own  purposes.  Tlie  standard  default  opcode  is  200. 

300-377  DAT  16-bit  Data 

Opcodes  300  through  377  (octal)  arc  controlled  packets  with  user  data  in  16-bit  bytes  in  the 
data  field.  The  NCP  treats  all  64  of  these  opcodes  identically;  some  higher-level  protocols  use  the 
opcodes  for  their  own  purposes.  T  he  suindard  default  opcode  for  16-bit  data  is  300. 

16  UNC  Uncontrolled  Data 

This  is  an  uncontrolled  packet  with  user  data  in  8-bit  bytes  in  tlic  daUi  field.  It  exists  so  that 

user-level  programs  may  bypass  the  flow-control  mechanism  of  Chaosnet  protocol.  Note  tliat  the 
NCP  is  free  to  discard  these  packets  at  any  time,  since  they  arc  uncontrolled.  Since  UNC’s  are 
not  subject  to  flow  control,  discarding  may  be  necessary  to  avoid  running  out  of  buffers.  A 
connection  may  not  have  more  input  packets  queued  awaiting  the  attention  of  the  user  program 
than  the  window  size  of  the  connection,  except  that  you  arc  always  allowed  to  have  one  UNC 
packet  queued.  If  no  normal  data  packets  arc  in  use,  up  to  one  more  UNC  packet  than  the 
window  size  may  be  queued. 

UNC  packets  arc  also  used  by  the  standard  proUKol  for  encapsulating  packets  of  foreign 
protocols  for  transmission  through  Chaosnet  (see  chapter  6,  page  32). 

4.4  End-of-Data 

14  EOF  RndofFilc 

HOP  is  a  controlled  packet  which  serves  as  a  "logical  end  of  data"  mark  in  the  packet  stream. 
When  the  user  program  is  ignoring  packets  and  treating  a  Chaosnet  connection  as  a  conventional 
hylc-strc.ini  I/O  device,  the  NCP  uses  the  P.OF  packet  to  convey  tlic  notion  of  conventional  end- 
olTilc  from  one  end  of  tlic  connection  to  tlic  other.  When  the  user  program  is  working  at  tlic 
p.ickct  level,  it  may  transmit  and  receive  HOF’s. 

rOI'  (lackels  .ire  used  in  the  following  protocol  which  is  the  recoiinm'iulod  way  to  reli.ibly 
determine  ih.it  all  data  have  been  transrerred  before  dosing  a  connection  (in  applications  where 
that  is  an  inipoilant  consideration). 

I  he  important  issue  is  th.it  neither  side  may  send  a  C  I  S  until  both  sides  are  sure  that  all  the 
tin  I  hoe  lieeii  tiaiismitted.  After  sending  all  the  d.ila  it  is  going  to  send,  including  .m  F(')|- 
p  iikt  t  to  m  ilk  the  end,  the  seinlini’.  proi  ess  waits  for  all  p.iikels  to  h'-  .lekiiowledged.  T  his 
I  I,  IIH-,  ih.it  tlie  I'leoei  his  seen  .ill  ihe  d.il.i  and  know'-,  ih.ii  ini  mine  data  ne  in  (iime.  I  he 
1,’hii'  |‘ii"i..  ill'll  lines  Ihe  i.iiiiiu  i.iiiiii.  When  ill.  l'll•i\lln',  piuee's  sees  an  litis  it  knows 
ill  :i  iliie  'll  nil  nii'U  dal.i  |l  dms  iinl  i|>i  '  ihr  1 1 ’nii. ' 'imi  until  it  sei  die  m  luli  i  tliee  i|,  oi 
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until  a  brief  timeout  elapses.  The  timeout  is  to  provide  for  the  ease  where  the  sender’s  CLS  gets 
lost  in  the  network  (CI.S  cannot  be  retransmitted).  The  timeout  is  long  enough  (a  few  seconds) 
to  make  it  unlikely  that  tlic  sender  will  not  have  seen  tlic  acknowledgement  of  the  liOl-'  by  the 
time  tlie  timeout  is  over. 

To  use  this  protocol  in  a  bidirectional  fashion,  where  both  parties  to  tlie  connection  are 
sending  data  simuluincously,  it  is  necessary  to  use  an  asymmetrical  proUKol.  Arbitrarily  call  one 
party  the  user  and  the  other  die  server.  'I'lic  pro'.)col  is  that  after  sending  all  its  data,  each  party 
sends  an  fiOK  and  waits  for  it  to  be  acknowledged.  I'he  server,  having  seen  its  liOF 
acknowledged,  sends  a  second  EOF.  The  user,  having  seen  its  HOF  acknowledged,  looks  for  a 
second  HOF  and  then  sends  a  CLS  and  goes  away.  The  server  goes  away  when  it  sees  the  user’s 
CLS,  or  after  a  brief  timeout  has  elapsed.  Iliis  asymmetrical  protocol  guarantees  that  each  side 
gets  a  chance  to  know  that  both  sides  agree  that  all  the  data  have  been  transferred.  The  first 
Cl.S  will  only  be  sent  after  both  sides  have  waited  for  their  (first)  HOF  to  be  acknowledged. 

4.5  Low-level 

13  MNT  Maintenance 

MNT  is  a  special  packet  type  reserved  for  the  use  of  network  maintenance  programs.  Normal 
NCPs  should  simply  discard  any  MNT  packets  they  receive.  MN'f  packets  arc  an  escape 
mechanism  to  allow  special  programs  to  send  packets  that  arc  guaranteed  not  to  get  confused  with 
nonnal  packets.  MN'f  packets  arc  forwarded  by  bridges  although  usually  one  woukl  not  be 
depending  on  this. 

10  RUT  Routing  Information 

RUT  is  a  special  packet  type  broadcast  by  bridges  to  infonn  other  nodes  of  the  bridge’s 
ability  to  forward  packets  between  subnets.  The  .source  address  is  the  network  address  of  the 
bridge  on  die  subnet  on  which  the  RU  T  was  broadcast.  The  destination  address  is  zero.  T'he 
byte  count  is  a  multiple  of  4,  and  the  data  field  contains  a  scries  of  pairs  of  Ifi-bit  bytes:  a 
subnet  number  and  the  "cost"  of  getting  to  diat  subnet  via  this  bridge.  T  he  packet  number  and 
acknowledgement  fields  arc  not  used  and  should  contain  zero.  Sec  section  3.7,  page  13  for  the 
details. 

4.6  Connection  Stales 

A  user  process  gets  to  Chaosnet  by  means  of  a  capability  or  channel  (dependent  (Mi  the  host 
operating  system)  whicTi  corresponds  to  one  end  of  a  connection.  Associated  \'ith  this  channel  arc 
a  number  of  bud'eis  containing  controlled  p.ickcts  output  by  the  user  and  not  yet  receipted,  and 
data  packets  received  fmm  the  network  but  not  yet  read  by  the  user;  some  of  these  incoming 
packets  arc  in-order  by  jiackct  number  and  hence  may  be  road  by  the  user,  while  otheis  are  out 
of  order  and  cannot  be  read  until  p.ickcts  cailicr  in  the  stre.nn  have  been  leceived.  Ceitain 
control  packets  aic  also  given  to  the  user  as  if  they  were  data  packets.  These  aie  KhC.  ANS, 
Cl  S,  LOS.  I 'Oh.  ami  IJN(.’,  LOF  is  ilii'  only  type  lliai  can  ever  be  oul-of-oider. 
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Also  associated  with  the  channel  is  a  state,  usually  called  the  connection  state.  Full 
understanding  of  these  states  depends  on  the  descriptions  of  packet-types  above.  The  state  can  be 
one  of; 


Open  'ITie  connection  exists  and  data  may  be  transferred. 

Closed  'fhe  channel  does  not  have  an  associated  connection.  Either  it  never  had  one  or  it 

has  received  or  transmitted  a  CLS  packet,  which  destroyed  the  connection. 


Listening 
RFC  Received 
RFC  Sent 
Lost 


The  channel  docs  not  have  an  associated  connection,  but  it  has  a  contact  name 
(usually  contained  in  a  LSN  packet)  for  which  it  is  listening. 

A  Listening  channel  enters  this  state  when  an  RFC  arrives.  It  can  become  Open 
if  the  user  process  accepts  the  request. 

'Fhe  user  has  transmitted  an  RFC.  The  state  will  change  to  Open  or  Closed  when 
the  reply  to  the  RFC  comes  back. 

The  connection  has  been  broken  by  receiving  a  LOS  packet. 


Incomplete  Transmission 

The  connection  has  been  broken  because  the  other  end  has  ceased  to  transmit  and 
to  respond  to  SNS.  Hitlicr  the  network  or  the  foreign  host  is  down.  (ITiis  can 
also  happen  if  the  local  host  goes  down  for  a  while  and  then  is  revived,  if  its 
clock  runs  in  the  meantime.) 


Foreign  The  channel  is  talking  some  foreign  protocol,  whose  packets  arc  encapsulated  in 

UNC  packets.  As  far  as  Chaosnet  is  concerned  there  is  no  connection.  See 
chapter  6.  page  32  for  the  details. 
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5.  Higher-Level  Protocols 

'I'liis  chapter  briefly  documents  some  of  the  higher-level  protcxols  of  the  most  general  interest. 
There  arc  quite  a  few  other  protocols  which  arc  too  specialized  to  mention  here.  All  protcKols 
other  tlian  lire  STATUS  proUKol  arc  optional  and  are  only  implemented  by  those  hosts  that  need 
them.  All  hosts  arc  required  to  implement  the  STATUS  protocol  since  it  is  used  for  network 
maintenance. 

5.1  Status 

All  network  nodes,  even  bridges,  arc  required  to  answer  RFC’s  with  contact  name  STATUS, 
returning  an  A  NS  packet  in  a  simple  transaction.  This  protocol  is  primarily  used  for  network 
maintenance.  The  answer  to  a  STATUS  request  should  be  generated  by  the  Network  Control 
Program,  rather  than  by  spirting  up  a  server  process,  in  order  to  provide  rapid  response. 

ilic  STATUS  protocol  is  used  to  dctcnninc  whether  a  host  is  up.  to  determine  whether  an 
operable  path  through  the  network  exists  between  two  hosts,  to  monitor  network  error  statistics, 
and  to  debug  new  Network  Control  Programs  and  new  Chaosnet  hardware.  The  hostat  function 
on  the  l.isp  machine,  and  the  Hostat  command  of  die  CHATST  program  on  ITS  arc  user  ends 
for  this  protocol. 

The  first  32  bytes  of  die  ANS  contain  the  name  of  the  node,  padded  on  die  right  with  zero 
bytes.  T  he  rest  of  the  packet  contains  bliKks  of  information  expressed  in  16-bit  and  32-bit  words, 
low  byte  first  (pdpll/l.isp  machine  style).  The  low-order  half  of  a  32-bit  w'ord  comes  first.  Since 
ANS  packets  contain  8-bit  data  (not  16-bit),  machines  such  as  pdplOs  which  store  numbers  high 
byte  first  will  have  to  shufllc  the  bytes  when  using  this  protocol.  T  he  first  16-bit  word  in  a  block 

is  its  identification.  The  second  16-bil  word  is  die  number  of  16-bit  words  to  follow.  The 

remaining  words  in  the  block  depend  on  the  identification. 

This  is  the  only  block  type  currently  defined.  All  items  arc  optional,  according  to  the  count 

field,  and  extra  items  not  defined  here  may  be  present  and  should  be  ignored.  Note  diat  items 

after  the  first  two  arc  32-bit  words. 

wordO  A  number  between  400  and  777  octal.  This  is  400  plus  a  subnet  number.  TTiis 

bliKk  contains  information  on  this  host’s  direct  connection  to  tliat  subnet. 

word  1  I'hc  number  of  16-bit  words  to  follow,  usually  16. 

words  2-3  The  number  of  packets  received  from  this  subnet. 

words 4-5  The  number  of  packets  ir.insmiitcd  to  this  subnet. 

words  6-7  The  number  of  transmissions  to  this  subnet  aborted  by  collisions  or  because  the 

receiver  was  busy. 

words  8-9  ITie  nuiiiber  of  incoming  packets  from  this  subnet  lost  because  the  host  had  niU 
yet  read  a  previous  packet  out  of  the  iiilerfacc  iind  consequent^  the  interface 
could  not  capture  the  packet. 

words  10-11  Ihc  mimher  of  incoming  packets  from  this  sulmct  with  CRC  errors,  ilie  e  were 
either  (ransmiited  wioni',  oi  d.im.iged  in  transmission. 
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words  12-13  The  nutrtber  of  incoming  packets  from  this  subnet  which  had  no  CRC  error  when 
received,  but  did  have  an  error  after  being  read  out  of  the  packet  buffer.  'ITiis 
error  indicates  cither  a  hardware  problem  with  the  packet  buffer  or  an  incorrect 
packet  length. 

words  14-15  The  number  of  incoming  packets  from  this  subnet  which  were  rejected  due  to 
incorrect  length  (typically  not  a  multiple  of  16  bits). 

words  16-17  The  number  of  incoming  packets  from  this  subnet  rejected  for  other  reasons  (e.g. 

too  short  to  contain  a  header,  garbage  byte-count,  forwarded  too  many  times.) 

If  the  identification  is  a  number  between  0  and  377  iKtal.  this  is  an  obsolete  form.at  of  block. 
Tlte  identification  is  a  subnet  number  and  the  counts  arc  as  above  except  iliat  they  are  only  16 
bits  instead  of  32,  and  consequently  may  overflow.  This  format  should  no  longer  be  sent  by  any 
hosts. 

Identification  numbers  of  1000  octal  and  up  are  reserved  for  future  use. 

5.2  Pulsar 

For  network  maintenance  purposes,  certain  network  nodes  support  a  simple  transaction  with 
contact  name  PULSAR,  which  controls  a  "pulsar"  feature.  This  feature  periodically  transmits  a 
short  packet  which  can  be  used  to  test  and  adjust  cable  transceivers.  'I'he  packet  consists  of  the 
three  header  words,  a  zero  word,  and  a  word  of  alternating  ones  and  zeros.  It  is  addressed  to 
host  177777  which  is  guaranteed  not  to  exist. 

The  returned  ANS  contains  a  single  character,  which  is  a  digit.  A  0  means  that  the  pulsar  is 
turned  off.  Any  other  digit  indicates  the  number  of  sixtieths  of  a  second  between  pulses.  Sending 
an  RFC  with  a  digit  as  an  argument  sets  die  state  of  the  pulsar  to  tJiat  digit,  and  mums  an  ANS 
containing  the  new  state. 

5.3  Telnet  and  Supdup 

The  Vclnet  and  Supdup  prolwols  of  tlie  Arpanet  ft  HI.NFT]  [SUI’DUI^i  cxi;i  in  identical  form 
in  Chaosnet.  'Ihcsc  protocols  allow  access  to  a  computer  system  as  an  interactive  terminal  from 
another  network  node. 

Ihe  contact  names  arc  TELNET  and  SUPDUP.  I'he  direct  borrowing  of  the  Telnet  and 
Supdup  protocols  was  eased  by  their  use  of  S-bit  byte  streams  and  only  a  single  eonneLtion.  Note 
ihal  these  prot(K:ols  define  their  own  character  sets,  which  differ  from  each  other  and  from  the 
t  haosnet  Maud. lid  eharaetcr  set 

Ch.iosnct  contains  no  coiiiitcipart  of  die  INR/INS  attciilion-gelting  le.itiirc  of  die  Arpanet. 
The  Telnet  protocol  sends  a  packet  with  opcode  .701  in  pl.ice  of  the  INS  sign.il.  This  is  a 
(inilrolled  packet  and  hence  does  not  provide  Ihe  "out  of  haiu!"  fcaiiire  of  the  Aipaiiel  INS, 
however  it  is  saiisf.ictoiy  for  the  Telnet  "iiileirupt  proce..s"  and  "discard  oiilpot”  opeiaiioiis  on  the 
kinds  of  Ik'sIs  aitached  to  Chaosnet. 
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5.4  File  Access 

The  I'll-H  protocol  is  primarily  used  by  l  isp  machines  to  access  files  on  network  file  servers, 
n  s  and  TOl’S-20  arc  equipped  to  act  as  file  servers.  A  user  end  for  the  file  protocol  also  exists 
for  'l'OPS-20  and  is  used  for  general-purpose  file  transfer.  I'or  complete  documcnlalion  on  the  file 
protocol,  see  [Fll.l'|.  I'hc  Arpanet  file  transfer  protocols  have  not  been  implemented  on  the 
Chaosnet  (except  through  the  Arpanet  gateway  described  below). 


5.5  Mail 

'fhe  MAH.  prouxrol  is  used  to  transmit  inter-user  messages  through  the  Chaosnet.  'I'hc 
Arpanet  mail  protocol  was  not  used  because  of  its  complexity  and  poor  state  of  documentation. 
'ITiis  simple  protocol  is  by  no  means  titc  last  word  in  mail  protocols;  however,  it  is  adequate  for 
the  mail  systems  we  presently  possess. 

'fhe  sender  of  mail  connects  to  contact  name  MAIL  and  establishes  a  stream  connection.  It 
then  sends  the  names  of  all  the  recipients  to  which  tlie  man  is  to  he  sent  at  (or  via)  die  server 
host.  'I'he  names  are  sent  one  to  a  line  and  terminated  by  a  blank  line  (two  carriage  returns  in  a 
row),  'fhe  l  isp  Machine  character  set  is  used.  A  reply  (see  below)  is  immediately  returned  for 
each  recipient.  A  recipient  is  typically  just  the  name  of  a  user,  but  it  can  be  a  uscr-atsign-host 
sequence  or  anything  else  acceptable  to  the  mail  system  on  the  server  machine.  After  sending  the 
recipients,  the  sender  sends  the  text  of  the  message,  terminated  by  an  KOL.  After  die  mail  has 
been  successfully  swallowed,  a  reply  is  sent.  After  die  sender  of  mail  has  read  the  reply,  both 
sides  close  the  connection. 

In  die  MAIL  protocol,  a  reply  is  a  signal  from  the  server  to  the  user  (or  sender)  indicating 
success  or  failure,  fhe  first  character  of  a  reply  is  a  plus  sign  for  success,  a  minus  sign  for 
permanent  failure  (c.g.  no  such  user  exists),  or  a  percent  sign  for  temporary  failure  (e.g,  unable  to 
receive  message  because  disk  is  full).  Llic  rest  of  a  reply  is  a  human-readable  character  string 
explaining  the  situation,  followed  by  a  carriage  return. 

'file  message  text  transmitted  through  tlic  mail  protocol  normally  contains  a  header  formatted 
in  the  Arpanet  standard  fashion.  [RFC7.L)| 


5.6  Send 

fhe  SFNI)  protocol  is  used  to  transmit  an  interactive  message  (requiring  immediate  attention) 
between  users,  fhe  sender  connects  to  contact  .lame  SliNI)  at  die  machine  to  which  the  recipient 
is  logged  in.  fhe  remainder  of  the  RFC  packet  contains  the  name  of  the  person  being  sent  to. 
A  stream  connection  is  opened  and  the  nicss;ige  is  transmitted,  followed  by  <m  I 'OF.  both  sides 
close  .liter  following  the  eiid-of-d.ita  prritocol  described  in  section  4.4,  p.ige  24.  the  l.ict  that  the 
RF(.'  w.is  lespoiuled  to  aflirmativcly  indicates  that  the  recipient  is  in  fact  presem  aiul  .iccepting 
mess.iges.  I  he  mc'.vii'.e  text  should  begin  with  a  suitable  header,  naming  the  user  III. it  sent  the 
mc-.s.ige.  'fhe  siaiid.iiil  for  such  liearleis,  not  curienlly  ailhcrcd  to  by  all  hosts,  is  one  line 
form.iited  a^  in  the  lollmMiig  example: 

M-.oiiiiftl  I  MC  li/l.n/81  {)?:?{):\] 

Aiii.aii.ilii  n  pb  to  the  .uider  i.m  be  nniil.  mented  h\  se,in.liin('  foi  the  lirr.t  "(u  "  .nu!  u^ing  the 
SI  f'll)  pinlowil  to  ill  '  lii'-.t  fiillowiiig  tile  "(</ "  with  ihe  .iigiimenl  preceding  it. 
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5.7  Name 

'ITic  Nanic/Fingcr  protocol  of  the  Arpanet  [FINGF.R]  exists  in  identical  fonn  on  the  Chaosnet. 
Both  Lisp  machines  and  timesharing  machines  support  tliis  protocol  and  provide  a  display  of  the 
user(s)  currently  logged  in  to  them. 

The  contact  name  is  NAMH  which  can  be  followed  by  a  space  and  a  string  of  arguments  like 
the  "command  line"  of  the  Arpanet  protocol.  A  stream  connection  is  established  and  the  "finger" 
display  is  output  in  Lisp  Machine  character  set,  followed  by  an  FOF. 

Lisp  Machines  also  support  tlic  FINGFR  proUKol,  a  simple-transaction  version  of  the  NAME 
protocol.  An  RFC  with  contact  name  FINGER  is  transmitted  and  the  response  is  an  ANS 
containing  the  following  items  of  information  separated  by  carriage  returns:  the  logged-in  user  ID, 
the  location  of  the  terminal,  the  idle  time  in  minutes  or  hours-colon-minutes,  die  user’s  full 
name,  and  tltc  user’s  group  affiliation. 


5.8  Time 

The  lime  protocol  of  the  Arpanet  fllME]  exists  on  Chaosnet  as  a  simple  transaction.  An 
Rl'C  to  contact  name  TIME  evokes  an  ANS  containing  tlic  number  of  seconds  since  midnight 
Greenwich  Mean  Time,  Jan  1,  1900  as  a  32-bit  number  in  four  8-bit  bytes,  least-significant  byte 
first.  Some  computers— Lisp  machines,  for  example— which  don’t  have  hardware  calendar-clocks 
use  this  protcKol  to  find  out  the  date  and  time  when  they  first  come  up. 

5.9  Arpanet  Gateway 

This  prot(x:ol  allows  a  Chaosnet  host  to  access  almost  any  service  on  the  Arpanet  The 
gateway  server  runs  on  each  US  host  that  is  connected  to  both  networks.  It  creates  an  Arpanet 
connection  and  a  Chaosnet  connection  and  forwards  data  bytes  from  one  to  the  other.  It  also 
provides  for  a  one-way  auxiliary  connection,  used  for  the  data  connection  of  the  Arpanet  File 
I  ransfer  Protocol. 

The  RFC  packet  contains  a  contact  name  of  ARPA,  a  space,  the  name  of  the  Arpanet  host  to 
be  connected  to,  optionally  followed  by  a  space  and  the  contact-socket  number  in  octal,  which 
defaults  to  1  if  omitted.  The  Arpanet  Initial  Connection  Protocol  is  used  to  establish  a  bi¬ 
directional  8-bit  connection. 

If  a  (lata  [lackct  with  opcode  201  (octal)  is  received,  an  Arpanet  INS  signal  will  be 
tr.insmiitcd.  Any  data  bytes  in  this  packet  arc  transmitted  normally. 

If  a  data  packet  with  opcode  210  ((iclal)  is  received,  an  anxiliaiy  conncclion  on  each  network 
is  ot'cned.  Hie  liiM  eight  data  bytes  are  the  Chaosnet  contact  n.iinc  for  the  auxiliary  connection; 
ihe  user  should  send  an  RFC  with  this  name  to  the  seivei.  The  next  I'oiii  data  bytes  are  tile 
Ai panel  so(  ket  uuinher  to  he  connected  to,  in  the  wrong  order,  mosl-si;',nilic,int  byte  liisl.  The 
byte  si/e  of  llie  anxiliaiy  connection  is  8  bits. 

I  he  normal  elosini'  of  an  Aip  niel  connei  lion  coire-poiids  lo  an  I  ()L  packet,  (  losine  ilin'  to 
an  eiioi.  soeb  as  I  lost  Dead,  loiiesponds  lo  a  (  I  S  (lackel. 


|)M.:M()(iN:AMIll  It  10/ 


Chaosnet 


31 


Dover 


5.10  Dover 

A  press  file  may  be  sent  to  the  Dover  printer  by  coniieeting  to  contact  naitic  DOVER  at  host 
AI-CHAOS-11.  This  host  provides  a  protocol  translation  service  which  translates  tidin  Chaosnet 
stream  protocol  to  die  EFTP  protocol  spoken  by  the  Dover  printer.  Only  one  file  at  a  time  can 
be  sent  to  the  Dover,  so  an  attempt  to  use  this  service  may  be  reCnsecl  by  a  CI.S  packet 

containing  the  string  "BUSY".  Once  the  connection  has  been  established,  the  press  file  is 

transmitted  as  a  sequence  of  8Tiit  bytes  in  data  packets  (oiicodc  200).  It  is  ncccss,iry  lo  provide 
packets  rapidly  enough  to  keep  die  Dover’s  program  (Spruce)  from  timing  out;  a  packet  every 
five  seconds  suffices.  Of  course,  packets  are  normally  transmitted  much  more  rapidly. 

Once  the  file  has  been  transmitted,  an  EOF  packet  must  be  sent.  The  tran  mittcr  must  wait 
for  that  F.OF  to  be  acknowledged,  send  a  second  one,  then  close  dic  connection.  I  hc  two  F.OF’s 
arc  necessary  to  provide  the  proper  connection-closing  sequence  for  the  EFTP  protocol.  Once  the 
press  file  has  been  transmitted  to  the  Dover  in  this  way  and  stored  on  the  Dover’s  local  disk,  it 
will  be  prcKCS-scd  and  prepared  for  printing,  and  then  printed. 

If  an  error  message  is  returned  by  the  Dover  while  the  p'css  file  is  being  transmitted,  it  will 
be  reported  back  dirough  the  Chaosnet  as  a  TOS  containing  the  text  of  the  error  message.  Such 

errors  arc  fairly  common;  the  sender  of  the  press  file  should  be  prepared  to  retry  die  operation  a 

few  times. 

Most  programs  that  send  press  files  to  die  Dover  first  wait  for  the  Dover  to  be  idle,  using  the 
Foreign  Protocol  mcclianism  of  Chaosnet  to  check  the  status  of  die  Dover.  I  his  is  optitnial,  but 
is  courteous  to  other  u.scrs  since  it  prevents  printing  from  being  held  up  wliilc  additional  files  arc 
sent  to  the  Dover  and  queued  on  its  local  disk. 

It  would  be  possible  to  send  to  a  press  file  to  the  Dover  using  its  EFTP  protiKol  through  the 
Foreign  Protocol  mechanism,  ratlicr  than  using  the  AI-CHAOS-11  gateway  service,  iliis  is  not 
usually  done  because  EFTP,  which  requires  a  handshake  for  every  packet,  tends  to  be  very  slow 
on  a  timesharing  system. 
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6.  Using  Foreign  Protocols  in  Chaosnet 

As  seen  above,  foreign  protocols  which  arc  based  on  the  idea  of  a  bidirectional  (or 
unidirectional)  stream  of  8-bit  bytes  can  simply  be  adopted  wholesale  into  Chaosnet,  using  a 
Chaosnet  stream  connection  instead  of  whatever  stream  protocol  the  protocol  was  originally 
designed  for.  This  was  done  with  the  Arpanet  Telnet  protocol,  for  example. 

When  using  such  protocols  between  a  Chaosnet  process  and  a  process  on  a  foreigti  network,  a 
protocol-translating  gateway  stands  at  the  boundary  between  the  two  networks  and  has  a 
connection  on  both  networks.  Bytes  received  from  one  connection  arc  transmitted  out  the  other. 
If  the  protocol  uses  any  features  besides  a  simple  stream  of  bytes,  for  instance  special  out-of-band 
signals,  these  arc  translated  appropriately  by  the  gateway.  'ITie  connection  is  initially  set  up  by 
the  user  end  connecting  explicitly  to  die  proUKol-translating  gateway  and  demanding  of  it  a 
certain  service  from  a  certain  host  on  the  other  network;  the  gateway  then  opens  the  appropriate 
pair  of  connections.  For  an  example  of  this,  refer  to  the  Arpanet  gateway  (see  section  5.9,  page 
30). 


However,  there  are  many  packet-oriented  protocols  in  the  world  and  sometimes  it  is  desirable 
to  access  these  protocols  at  the  packet  level  rather  than  the  connection  level,  and  to  transport  the 
packets  of  these  protocols  through  Chaosnet  links  without  using  a  Chaosnet  connection.  For 
example,  there  are  gateways  attached  to  Chaosnet  which  provide  connections  to  other  networks 
that  use  PUP  and  Internet  as  their  packet  protocols.  User  processes  in  Chaosnet  hosts  may  talk  to 
fiiesc  other  networks  in  those  networks'  own  protocols  by  using  the  foreign-protocol  protocol  of 
Chaosnet. 

A  foreign  packet  is  transmitted  through  Chaosnet  by  storing  it  in  the  data  field  of  an  UNC 
packet.  'Hie  foreign  packet  is  regarded  as  being  composed  of  8-bit  bytes.  'Hie  source  and 
destination  addresses  of  the  UNC, packet  arc  used  in  the  usual  fashion  to  control  the  delivery  of 
the  packet  within  Chaosnet.  Hie  packet  number  and  acknowledgement  fields  of  the  packet  header 
arc  not  used  for  tlicir  normal  purposes,  since  this  packet  is  not  associated  with  a  Chaosnet  stream 
connection.  By  convention,  die  acknowledgement  field  of  the  packet  contains  a  protocol  number. 
The  number  100000  octal  means  Internet  and  the  number  100001  octal  means  PUP.  Other 
numbers  will  be  assigned  as  needed.  The  packet  number  field  of  die  packet  can  be  used  for  any 
purpose. 

If  a  user  prtKcss  transmits  an  UNC  packet  through  a  Ch.iosnet  channel  which  is  in  the  Closed 
state  (see  section  4.6.  page  25),  the  channel  goes  into  the  I'orcinii  slate  and  the  NCP  assumes  that 
the  user  is  not  talking  normal  Chactsnet  protocol,  but  is  using  Chaosnet  to  transport  packets  of 
some  other  protocol.  The  NCP  (ills  in  the  source  address  .ind  index  in  these  packets,  hut  believes 
wliatevcr  destination  address  and  index  are  pt.aced  in  the  packet  by  the  user,  liic  packet  number 
and  .acknowledgement  fields  of  the  UNC  packets  arc  not  touched  by  the  NCP.  Any  incoming 
LINC  packets  addressed  to  the  user's  index  on  this  host  will  be  given  to  the  user,  regardless  of 
their  source  address/index;  it  is  up  to  the  user  program  to  filter  out  any  unwanted  packets.  The 
N(T  should  also  piovide  a  way  for  one  user  to  receive  any  unclaimed  incoming  UNC  packets,  so 
th.it  renckvvous  siibprotocols  of  foreign  protocols  may  be  simul.ited. 

When  a  packel-lr.insla|jn,g  gateway  to  a  forei.gii  network  receives  an  UNC  p.ickel  with  the 
,ippiopii.iie  protocol  numher.  it  cxir.icts  the  foreign  p.ickei  lioin  the  dat.i  held  .nul  lues  it  into  the 
l()iei;’n  net'Aoik.  When  it  receives  p.ickets  I'lom  the  loieii'ii  lutwork,  it  m.ips  the  ikstin.ition 
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address  of  die  packet  into  a  Chaosnet  address  and  index  in  some  suitable  fisluon,  encapsulates 
tlie  packet  in  an  UNC,  and  launches  it  into  Chaosnet. 

For  PUP  the  address  mapping  is  straightforward,  since  PUP  and  riiuisnet  use  similar 
addressing  techniques  [I•'|■HHRNR'^|.  The  host  address  spaces  are  the  same.  I  he  Chaosnet  index 
maps  directly  into  the  low-order  16  bits  of  the  PUP  port  number,  and  the  high-order  16  bits  are 
zero.  When  a  PUP  is  encapsulated  in  a  Chaosnet  packet,  its  PUP  header  duplic.iics  the  addresses 
in  the  Chaosnet  header.  When  a  PUP  is  received  by  a  PUP/Chaosnei  g.newa),  a  Chaosnet 
header  can  easily  be  constructed  from  lire  PUP  header.  Ihe  Al-CllAOS-11  is  attached  to  the 
Mil'  Chaosnet  and  the  MU'  Hthernct  and  provides  a  PUP/Chaosnet  gtitewav.  it  advertises  to 
each  network  its  ability  to  route  packets  to  host  addresses  in  tlie  other  network,  using  that 
network’s  rttuting  protocols.  When  it  receives  a  packet  from  one  network  tiiat  is  de.stincd  for  the 
other,  it  docs  the  appropriate  encapsulation  or  dc-cncapsulation  and  sends  the  packet  on  its  way. 
AI-CHAOS-11  also  acts  as  ;i  bridge  between  several  Chaosnet  subnets  and  provides  a  protiKol- 
translaling  gateway  for  sending  Press  files  to  the  Dover  printer  (a  protiKol-translating  gateway  is 
necessary  for  iliis  application  because  the  printer’s  mitivc  prottKol,  which  could  be  used  through 
tlie  foreign-protocol  proUKol,  cannot  be  implemented  efficiently  under  a  timesharing  system). 

In  the  ease  of  Internet,  only  protocols  built  on  the  idea  of  ports  can  be  straightforwardly 
supported  without  a  table  of  connections  in  the  gateway.  The  Internet  address  space  includes  the 
Chaosnet  host  addiuss  .space  as  a  subset  but  does  not  provide  any  address  breakdown  within  a 
host  unless  ports  arc  used.  However,  it  appears  that  most  protocols  are  built  on  a  protocol  that 
uses  ports,  such  as  the  User  Datagram  Protocol  [UDP]  or  the  'fransmissiun  (Jontrol  Protocol 

rrcp]. 

In  the  ease  of  foreign  protocols  other  than  PUP,  where  the  addressing  structure  is  not 
identical  to  Chaosnet,  a  program  must  somehow  know  the  Chaosnet  address  of  a  packet- 
translating  gateway  to  the  foreign  network.  By  sending  UNC  packets  to  this  gateway,  a  user 
program  can  initiate  connections  to  processes  on  that  other  network  without  requiting  his  local 
NCP  (nor  any  bridges  involved  in  routing  die  packets)  to  know  anything  about  the  nrotocol  he  is 
using.  If  Uie  inter-network  gateway  translates  rende/vous  protocols  appropriately,  connections  may 
be  initiated  in  the  reverse  direction  also — from  a  user  process  on  the  foreign  network  to  a  server 
for  the  foreign  protocol  that  resides  on  a  Chaosnet  liost. 

The  forcigti-proUK'ol  protwol  may  ;ilso  be  used  between  two  user  processes  on  Chaosnet,  with 
no  foreign  network  involved,  if  they  simiily  wish  to  speak  a  dillercnt  protocol  from  Chaosnet, 
they  arc  on  their  own  for  a  rende/vous  mechanism,  liowcvci.  unless  they  use  a  Chaosnet  simple 
transaction  for  rendezvous  or  otherwise  have  some  way  of  coioeving  their  addresses  and  index 
ntimbcrs  to  each  other. 

When  foreign  packets  arc  too  large  to  lit  in  the  data  field  of  it  Chaostict  packet  (more  tlian 
488  hytes),  the  user  program  ;ind  the  p.ieket-iraiislaling  gateway  must  agree  on  a  technique  for 
dividing  packets  into  I'r.ig.mettis  and  rc.is'.''iiihliug  Ihctn,  unless  the  I'oieign  protocol  itself  pro' ides 
for  this,  .is  Internet  does.  The  packet  immhcr  Held  in  an  UN('  p.iekct  is  .ivail.ible  lor  use  by 
such  a  (ec  liniiiue.  since  I  INC  ptickets  are  not  norniallv  niimiK'icd.  I  his  is  not  a  problem  with 
I'UI’,  since  it  pKiviiles  ,i  piotoeol  by  whult  p, lilies  to  ,i  lomi''' lion  iind  ealeways  m.iy  tomplain 

aboiil  ovcily-laii'c  packets  and  speedy  the  iiiaxinmm  ji.ii  kel  size  lo  be  Used, 

I  INC  |i.nkels  not  a•,■;ol:l.lled  with  .i  eomici  tiuii  .iie  useful  I'm  oilier  things  besides  ei'L.ipsiil.iting 
Imeirn  ('rolocols,  \ny  ,i|)plie,ii ion  whieli  w.iiiis  lo  usi'  (  li  losiu  '  is  smipK  ,t  piU  et  liaiisinission 

metlium,  e.semi.illv  the  r.iv.  h.iidw.ne,  ■ll•'.|ld  use  I  N(  p,ii  1  eis  -o  lii.ii  iis  |i,;  ke|s  ;|o  not 
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interfere  with  standard  packets  and  so  that  the  standard  routing  mechanisms  may  be  used.  For 
example,  the  Mi'l'  Architecture  Machine  uses  UNC  packets  to  communicate  with  non-stream- 
oriented  I/O  devices  such  as  graphic  tablets.  Here  Chaosnet  is  being  used  as  an  I/O  bus  which 
may  be  attached  to  more  than  one  computer.  Numbers  between  140000  and  177777  octal  in  the 
acknowledgement  field  of  an  UNC  packet  are  reserved  for  such  applications.  Note  that  this 
number  is  not  part  of  the  protocol;  it  is  simply  a  hint  about  what  a  packet  is  being  used  for. 
Normally  no  program  that  is  not  specifically  supposed  to  deal  with  such  packets  would  ever 
receive  one. 
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7.  Hardware  Programming  Documentation 

This  section  describes  llie  Unibus  version  of  the  Chaosnet  interface,  which  attaches  lu  pdplls 
and  l.isp  Machines.  The  interface  contains  one  biiflcr  which  holds  a  received  packet  and  a  second 
bulfer  which  holds  a  packet  to  be  transmitted.  Packets  are  moved  between  Uicsc  buliers  and  the 
computer  under  program  control.  Direct  memory  access  (DMA)  is  not  used:  the  small  gain  in 
performance  was  not  tliought  to  be  worth  the  extra  hardware  complexity.  The  usual  performance 
penalty  of  programmed  I/O  is  not  incurred  since  the  packet  bull'ers  can  transfer  data  a(  the  full 
speed  of  the  computer  and  ncitlier  busy  waiting  nor  multiple  interrupts  arc  required. 

To  transmit  a  packet,  successive  16-bit  words  of  the  packet  are  written  into  die  outgoing 
packet  buffer.  The  last  word  to  be  written  is  the  cable  address  of  the  destination  of  the  packet, 
or  0  to  broadcast  it.  The  hardware  is  then  told  to  initiate  transmission.  It  waits  until  tlte  cable  is 
not  busy  and  this  node’s  turn  to  transmit  arrives,  then  shifts  the  packet  out  onto  the  cable.  At 
the  completion  of  transmission  transmit-donc  is  set  and  tire  computer  is  interrupted.  If 
transmission  is  aborted  by  a  collision,  transmit  done  and  transmit-abort  arc  set  and  the  computer 
is  interrupted.  As  the  packet  is  written  into  the  outgoing  packet  bulfer,  a  16-bit  cyclic  redundancy 
checksum  is  computed  by  the  hardware.  This  checksum  is  transmitted  with  the  packet  and 
checked  by  the  receiver. 

To  receive  a  packet,  die  clcar-rcccivcr  bit  is  asserted  by  the  program.  The  next  packet  on  the 
cable  which  is  addressed  to  diis  node,  or  is  broadcast,  will  be  stored  into  the  incoming  packet 
buffer.  After  the  packet  has  been  stored,  the  computer  is  interrupted.  I’hc  packet  bulfer  will 
tlien  not  be  changed  until  the  next  dear-receiver  operation  is  performed,  giving  the  computer  a 
chance  to  read  out  the  packet.  If  a  packet  appears  on  the  cable  addressed  to  this  node  while  the 
incoming  packet  buffer  is  busy,  a  collision  is  simulated  so  as  to  abort  the  transmission.  As  a 
packet  is  stored  into  the  incoming  packet  bulfer,  the  16-bit  cyclic  redundancy  checksum  is 
checked,  and  it  is  checked  again  as  the  packet  is  read  out  of  die  packet  buffer.  I  bis  provides  full 
checking  for  errors  in  the  network  and  in  the  packet  buffers. 

flic  standtird  interrupt-vector  address  for  the  Chaosnet  interface  is  270.  The  standard  interrupt 
priority  level  is  5.  I  hc  suindard  Unibus  address  is  764140.  Ihc.se  arc  the  device  registers: 

764140  C  oiinihuiil/Slatus  Register 

I'his  register  contains  a  number  of  bits,  in  the  usual  pdpll  style.  All  rcad/write  bits  are 
initiali/ed  to  zero  on  power-up.  Identified  by  dicir  masks,  these  are: 

1  rimer  Interrupt  l-.nabic  (re.id/wrilc).  T.nablcs  interrupts  from  the  interval  dmer 
present  in  some  versions  of  the  interface  (not  des^  ribed  here). 

2  I  ()0|i  l{ai:k  (rcad/write).  If  this  bit  is  1.  the  cable  and  transceiver  are  not  used 
and  the  interface  is  looped  back  to  itself.  I  his  is  for  maintenance. 

4  Spy  (re.id/wrilc).  If  this  hit  is  1,  the  inieilace  will  receive  all  p.ickets  regaidless 
of  their  ilcstin.ition.  Ibis  is  for  inaintemmee  ami  netwoik  moiiilming, 

10  Cle.ir  Receiver  (wiitc  only).  Wiitmg  a  1  into  this  hit  t.leais  Receive  Done  and 
enables  the  receiver  to  rveeive  another  packet, 

20  Receive  Inii.’irupl  I  ii.ihle  (rcad/write).  If  Receive  I  lone  and  Rcn'i'  C  Interrupt 
1  ii.ible  ,iie  both  1.  the  iompiiui  is  interi ii|ited. 
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764142 

764142 

764144 

764146 

764152 


40  Transmit  Interrupt  Pnablc  (read/writc).  If  Transmit  Done  and  I'ransmit 

Interrupt  Hnablc  arc  both  1,  the  computer  is  interrupted. 

100  'I'ransmit  Abort  (read  only).  This  bit  is  1  if  the  last  transmission  was  aborted, 
by  a  collision  or  because  the  receiver  was  busy. 

200  Transmit  Done  (read  only).  This  bit  is  set  to  1  when  a  transmission  is 
completed  or  aborted,  and  cleared  to  0  when  a  word  is  written  into  tlic  outgoing 
packet  buffer. 

400  Clear  Transmitter  (write  only).  Writing  a  1  into  this  bit  stops  the  transmitter 
and  sets  Transmit  Done.  This  is  for  maintenance. 

17000  l.ost  Count  (read  only).  These  4  bits  contain  a  count  of  the  number  of  packets 
which  would  have  been  received  if  the  incoming  packet  buffer  had  not  been 
busy.  Setting  Clear  Receiver  resets  tlie  lost  count  to  0. 

20000  Reset  (write  only).  Writing  a  1  into  this  bit  completely  resets  the  interface,  just 
as  at  power  up  and  Unibus  Initialize. 

40000  CRC  Hrror  (read  only).  If  this  bit  is  1  the  receiver's  cyclic  redundancy 
checksum  indicates  an  error.  This  bit  is  only  valid  at  two  times:  when  the 
incoming  packet  buffer  contains  a  fresh  packet,  and  when  die  packet  has  been 
completely  read  out  of  the  packet  buffer. 

100000  Receive  Done  (read  only).  A  1  in  this  bit  indicates  tliat  the  incoming  packet 
buffer  contains  a  packet. 

My  Address  (read) 

Reading  this  location  returns  the  network  address  of  this  interface  (which  is  contained  in  a 
set  of  DIP  switches  on  the  board). 

Write  Ituffer  (write) 

Writing  diis  location  writes  a  word  into  the  outgoing  packet  buffer.  The  last  word  written 
is  the  destination  address. 

Read  Buffer  (read  only) 

Reading  this  location  reads  a  word  from  the  incoming  packet  buffer.  The  last  three  words 
read  arc  the  destination  address,  the  source  address,  and  tlic  checksum. 

Bit  Count  (readonly) 

This  location  contains  the  number  of  bits  in  the  incoming  packet  buffer,  minus  one. 
After  tlic  whole  packet  has  been  read  out,  it  will  contain  7777  (a  12-bit  minus-one). 

Start  I raiistiiissioii only) 

Rcailing  this  location  initi.itcs  trausmi.ssion  of  the  packet  in  the  outgoing  packet  Inilfcr. 
Hie  value  lo.id  is  the  network  address  of  this  inlerfacc.  This  method  for  sl.iiting 
tr.insniission  may  .seem  strange,  but  it  makes  it  e.isier  for  the  haidwaie  to  get  the  source 
address  into  the  p.ickct. 
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8.  The  ITS  Implementation 

8.1  System  Calls 

Note  that  the  NETWRK  subroutine  package,  page  42,  provides  a  conveiiieiu  interface  to  most 
of  these  system  calls  for  the  assembly-language  programmer. 

8.1.1  Opening  I/O  Channels 

Since  MS  I/O  Channels  arc  unidirectional,  a  Chaosnet  connection  is  represented  by  a  pair  of 
channels,  one  for  input  and  one  for  output.  Operations  tlint  are  not  inhcrentlv  directional,  such 
as  finding  out  the  state  of  the  connection,  may  be  done  on  either  channel  (it  makes  no 
difference). 

Unlike  every  other  device,  you  do  not  obtain  these  channels  with  the  OPEN  system  call. 
Instead  a  special  system  call,  CHAOSO,  is  provided.  'I'his  docs  not  open  a  connection;  it  simply 
gives  you  a  pair  of  channels  and  a  potential  connection,  in  die  f  suite,  which  can  be  opened 
by  transmitting  a  packet  (an  RFC  for  insuincc)  through  the  output  channel. 

CHAOSO  takes  tlirec  arguments:  the  input  channel  number,  the  output  channel  number,  and 
the  receive  window  .size.  If  either  channel  is  currently  open  it  is  closed  first  (just  as  with  OPEN). 
CHAOSO  returns  no  values.  Hrror  6  (device  full)  is  signalled  if  the  iysicm's  connection  table  is 
full. 

8.1.2  Input  and  Output 

Input  and  output  can  be  done  on  a  Chaosnet  connection  in  terms  of  either  packets  or  8-bit 
bytes.  8-bit  byte  I/O  is  usually  done  with  the  SIOT  system  call;  the  lOT  system  call  or  the  .lOT 
uuo  may  also  be  used —the  channel  behaves  as  if  it  had  been  opened  in  unit  mode.  8-bit  byte 
output  is  collected  by  llic  system  into  packets  containing  the  maximum  allowed  number  of  bytes; 
when  a  packet  is  full  it  is  transmitted  with  the  standard  daUi  opcode  (200).  Until  a  lull  packet’s 
worth  of  bytes  have  been  output  nothing  will  be  iransmitied  unless  the  FORCE  system  call  is 
used.  8-bit  input  comes  from  packets  with  the  data  opcode  (200).  If  an  I'.OI-  p.icket  is  received, 
the  standard  eiuTof-file  behavior  will  occur— lOT  will  return  the  EOF  char.icter  (-1„3)  and  SIOT 
will  return  with  a  non-zero  residual  byte  count.  II  some  other  kind  of  p.icket  is  received,  .in  IOC 
error  will  be  signalled  (see  below).  If  PKTIOT  (see  below)  is  used  to  re, id  out  a  noii-d.ita  packet, 
stream  injuit  may  be  contiiuicd  past  it. 

Hit  1.4  in  the  conirol  bits  is  "don't  hang"  mode  for  both  input  and  output.  When  SIOT  is 
done  with  this  bit  specified,  and  no  input  is  .tv.nlable  or  the  output  window  is  full,  it  will  simply 
return  wilhout  tr.insleiiing  the  full  niiinber  of  bytes  specified.  I  he  byte  pointci  an.l  byte-count 
arguments  to  SIOT  .iie  npd.ited  past  the  bytes  lh.it  were  tr.uisfei red.  When  input  lOT  is  dime  in 
"ilon't  haiir,"  mode,  uni  no  input  is  a\  ulabli'.  the  I'Ol  eharaeler  (-1  ,.l)  is  relmned.  ttiilpiit  lOT 
should  not  be  done  in  "don’t  li.iiig"  mode  sjiue  it  has  no  w.iv  to  indicate  ih.it  it  did  not  traiisiiiit 
.iiiything.  It  1  non  d  ii.i  packet  is  iccei'.etl  "doii'i  hang,"  mode  will  beli  oe  the  s.iine  .is  if  there 
was  no  inpm  .o.iil.ible. 
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Before  doing  8-bit  byte  I/O,  the  user  program  must  open  a  Chaesnet  stream  connection  by 
transmitting  and  receiving  the  appropriate  RFC,  LSN,  or  OPN  packets  and  following  the  protocol 
described  on  page  21.  llie  NETWRK  subroutine  package  can  be  useful  for  this. 

Input  and  output  can  be  done  in  terms  of  packets  by  using  the  PKTIOT  system  call.  The  first 
argument  is  the  I/O  channel  number  and  the  second  is  the  address  of  the  packet  to  be 
transmitted  or  of  a  126.-word  buffer  to  contain  the  packet  to  be  received.  No  values  are  returned. 

Input  PKTIOT  will  return  data  packets  and  the  following  types  of  control  packets:  RFC, 
OPN,  FWD,  ANS,  Cl.S,  LOS,  FOl',  and  UNC.  TTie  other  types  of  control  packets  are  for  the 
NCP's  internal  use  only.  If  no  input  packets  arc  available,  PKTIOT  will  wait.  If  the  connection 
is  in  a  bad  state,  an  IOC  error  wilt  be  signalled.  This  is  discussed  in  the  next  section. 

Output  PKTIOT  will  accept  data  packets  and  CLS,  I'.OF,  and  UNC  packets  if  the  connection 
is  open.  Transmitting  an  UNC  packet  when  the  connection  is  closed  puts  it  into  the  Foreign 
Protocol  state.  RI-C,  LSN,  OPN,  FWl),  and  ANS  packets  may  be  transmitted  if  the  connection 
is  in  the  appropriate  state.  Transmitting  a  bad  packet  type  or  transmitting  when  the  connection  is 
in  the  wrong  state  signals  an  IOC  error  (see  the  next  section).  Normally  the  user  sets  only  the 
opcode  and  number  of  bytes  fields  in  die  packet  header;  PKTIOT  fills  in  Uie  rest.  When  sending 
an  RFC,  the  user  specifies  the  destination-host  field  and  the  system  remembers  it.  When  sending 
an  UNC,  the  user  specifies  everything  but  the  source  host  and  index. 

Note  that  PKTIOT  docs  not  synchronize  with  8-bit  byte  I/O.  If  a  partial  packet’s  worth  of 
bytes  have  been  output,  and  then  a  packet  is  output  with  PKTIOT,  that  packet  will  get  ahead  of 
those  bytes.  The  FORCE  system  call  can  be  used  to  change  this.  If  a  partial  packet’s  worth  of 
bytes  have  been  input,  and  then  a  PKTIOT  is  done,  tliose  bytes  will  remain  available  to  the 
stream  and  PKTIOT  will  read  the  next  packet  after  them. 

8.1.3  Interrupts 

I/O  (second-word)  interrupts  (Kcur  if  enabled  when  an  I/O  operation  formerly  would  have 
hung  but  now  will  not.  In  other  words,  an  interrupt  occurs  on  the  input  channel  when  a  packet 
arrives  while  tlicrc  arc  no  input  packets  available,  if  die  packet  is  of  a  type  diat  input  PKTIOT 
would  return.  An  interrupt  wcurs  on  the  output  channel  if  the  window  is  full  and  an 
acknowledgement  arrives  which  makes  some  space  in  the  window.  Completely  interrupt-driven 
I/O  can  easily  be  programmed  for  the  Chaosnet,  using  the  WHYINT  system  call  (see  below). 

An  interrupt  also  iKciirs  on  the  input  channel  when  the  connection  state  changes. 

A  %PIIOC  inleriupt  (also  r.illed  an  "IOC  error")  occurs  if  any  of  a  variety  of  illegal 
opeiations  is  performed.  IOC  error  3  (non-recovcrable  data  error)  is  signalled  if  a  iraeket  is 
tr.insmitied  wiih  PKTIOT  and  it  has  an  illegal  si/e  or  opvode  in  the  header.  IO(.'  error  12  octal 
(rhannel  in  illegal  mode)  is  sign, ailed  if  byte  or  packet  input  or  output  is  done  with  the 
connection  in  the  wrong  slate,  or  if  byte  input  is  rlone  ami  a  packet  other  than  a  normal  data 
|i.i(  kel  or  T.OT  is  found. 
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8.1.4  IVIisccllaneous  Operations 

'I’hc  CLOSE  system  call,  or  the  .CLOSE  uuo,  may  be  used  to  close  the  I/O  channels  and  the 
connection.  When  both  channels  arc  closed,  all  bulTcrs  and  other  int'ormatkm  associated  m\i\  the 
connection  arc  immediately  discarded.  If  the  connection  is  open  a  CLS  packet  is  transmitted. 
You  can  also  transmit  a  CI.S  yourself,  with  an  explanatory  message  in  it,  before  doing  the 
CLOSE. 

The  FORCE  system  call,  or  the  .NETS  luio,  can  be  used  on  an  oulput  channel.  If  there  is 
bulTcr  containing  a  partial  packet's  worth  of  8-bit  byte  output,  it  is  transmitted  as  a  packet  of  less 
than  the  maximum  size. 

Tlic  FINISH  system  call  first  does  a  FORCE  and  then  waits  for  all  packets  that  have  been 
transmitted  to  be  acknowledged. 

T'hc  RESET  system  call,  and  tlte  .RESET  uuo,  arc  ignored,  as  on  most  devices.  The  RCHST 
and  RENAME  system  calls,  and  tlie  .RCHST  uuo,  return  the  standard  information  for  a  non-file 
device,  with  device-name  CHAOS:.  No  device-dependent  information  is  returned. 

nic  WHYINT  system  call,  given  either  the  input  channel  or  the  output  channel  of  a  Chaosnet 
connection,  returns  a  lot  of  useful  device-dependent  information  about  the  connection: 

val  1  'I  hc  device  code,  which  is  the  value  of  tlic  symbol  %WYCHA. 

val  2  The  state  of  the  coiYttcclion.  Symbols  for  the  connection  states  start  with  foe  prefix  %CS; 
%CSCLS  Closed  (or  never  opened). 

%CSLSN  Listening  for  an  incoming  RFC. 

%CSRFC  RFC  received  while  listening;  neither  accepted  nor  rejected  yet. 

%CSRFS  RFC  sent,  awaiting  acceptance,  rejection,  or  answer. 

%CSOPN  Open. 

%CSLOS  Broken  by  receipt  of  a  I  OS  packet. 

%CSINC  Broken  by  "incomplete  transmission"  (no  response  from  foreign  host  for  a 
long  time). 

%CSFRN  Using  a  foreign  protocol,  encapsulated  in  UNC  packets. 

val  3  I  he  left  half  is  the  number  of  available  input  packets.  I  his  docs  not  count  out-of-order 
p.ickels.  I  his  number  is  increased  by  one  if  iherc  is  bi.'lered  input  available  for  8-bit 
byte  input.  I'his  luimber  is  zero  if  the  Chaosnet  connection  is  directly  connected  to  a 
S  I  Y  (sec  STYNET). 

The  right  half  is  the  number  of  output  packets  which  have  not  yet  been  acknowledged 
and  lienee  are  occu|)yitig  space  in  the  window. 

v;il  4  Ihc  lefl  half  is  the  receive  window  '.i/e  and  the  right  half  is  the  tninsmil  window  si/e. 

val  5  llic  left  h.iK  is  the  input  ch.inn'-l  numl'cr  .aid  the  lij  lit  h.ilf  is  the  output  channel 
nnnibet.  Ihc'e  innulieis  aie  -I  il  the  cli.iniivl  has  been  Ul.('.'3l.d  or  lOI'USI  leil. 
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lire  NETBLK  system  call  works  similarly  on  the  Chaosnet  as  on  llie  Arpanet.  I’he  first 
argument  is  a  channel  number  (input  or  output).  The  second  argument  is  a  connection  state  code. 
The  third  argument,  which  is  optional,  is  a  timeout  in  BOths  of  a  second.  If  it  is  not  immediate 
it  is  modified.  NETBLK  hangs  until  tlie  connection  state  is  different  from  the  specified  state  or 
the  timeout  (if  specified)  elapses.  Two  values  arc  returned:  the  current  state  of  the  connection 
and  the  amount  of  time  left 

'The  STYNET  system  call  works  similarly  on  the  Chaosnet  as  on  the  Arpanet.  It  allows  a 
Chaosnet  connection  and  a  SIT  (pseudo  terminal)  to  be  connected  together  so  that  a 
Telnet/Supdup  server  program  can  provide  efficient  service.  The  arguments  arc: 

arg  1  'ITie  STY  channel  number. 

arg2  'fhe  Chaosnet  input  channel  number  to  connect  it  to.  or  -1  to  disconnect  it. 

arg  3  'The  Chaosnet  output  channel  number.  1'his  is  not  actually  used  on  the  Chaosnet. 

arg 4  Up  to  three  8-bit  characters,  Icfl-justificd,  to  be  transmitted  when  an  output-reset  is  done 
on  the  terminal.  These  characters  arc  protocol-dcpendcnL  If  any  unusual  condition 
cccure,  including  input  of  a  byte  with  the  high-order  bit  on  from  the  network,  the  STY 
will  be  disconnected  from  the  Chaosnet  channel  and  the  user  will  be  interrupted.  It  is 
illegal  to  do  I/O  on  any  of  the  involved  channels  without  disconnecting  them  from  each 
other  first 

The  CHAOSO  system  call  allows  the  ATSIGN  CHAOS  program,  described  below,  to  peek  at 
the  queue  of  pending  RFC’s.  It  takes  one  argument,  which  is  the  address  of  a  Hfi-word  buffer. 
The  first  RFC  packet  on  the  queue  is  copied  into  tltis  buffer  and  moved  to  the  end  of  the  queue. 
If  the  queue  is  empty,  the  system  call  takes  the  error  return. 

8.2  Utility  Programs 

The  K  mode  in  the  :PEEK  command  gives  one  line  of  information  for  each  Chaosnet 
connection  in  existence  on  tlie  local  machine,  lists  the  number  of  packet  buffers  in  existence  and 
free,  and  lists  any  queued  RFC’s  (sec  the  following  section).  Packet  buffers  arc  dynamically 
allocated  in  groups  of  8  from  system  memory.  Packet  buffcis  in  existence  and  not  free  may  be  in 
use  to  contain  packets  being  transmitted  to  or  received  from  the  liardwarc,  unreceipted  output 
packets,  or  input  packets  not  yet  r-’ad  by  the  user  program. 

The  information  about  a  Chaosnet  connection  printed  by  PEEK  consists  of: 

IDX  The  connection  index  number  (not  including  the  imiquiwtion  bits). 

USR  Tlie  user  index  or  U  S  job  number  of  the  user  process  which  owns  the  connection. 

IJNAME 

JNAME  I  he  name  of  the  user  process  which  owns  the  connection. 

STATE  The  state  of  the  connection.  'I'his  is  one  of  tlie  states  listed  in  section  4.6,  page 

25.  abbreviated  to  six  ch.iraclcrs.  IOWI.VI,  nicMii.s  the  foivign  piolncol  si.ite. 

IBF  Ihc  miinher  of  input  packets  bufl'ereil  and  available  to  he  lead  by  the  user 

pilK-CSS. 

PHF  I  he  niimhcr  of  input  pac  kets  huHcied  tnit  not  ^el  a\  lilable  to  the  user  puK'ess 

because'  they  are  out  dI'  cnlcr.  .Some  e.iilii a  p.n  kels  .iie  niis-.iiiy:  wlii'ii  they  anivc 
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these  packets  will  become  available. 

NOS  The  number  of  output  "slots"  available  in  tlic  window.  The  user  process  may 

send  this  many  packets  before  it  will  have  to  wait  for  an  acknowledgement. 

ACK  The  number  of  received  packets  which  should  be  acknowledged  but  which  have 

not  yet  been.  This  will  not  stay  non-zero  for  more  than  a  half  second,  since  if  it 
is  non-zero  an  SI’S  will  be  transmitted. 

R  WIN  I  hc  window  size  for  the  incoming  half  of  this  connection. 

WIN  T  I  hc  window  size  for  the  outgoing  half  of  tliis  connection. 

FOREIGN  ADDR 

'I’hc  host  name  and  index  number  of  the  other  end  of  this  connection.  The  = 
command  switches  between  host  names  and  host  numbers. 

FLAG  One  or  more  single-letter  flags  indicating  special  things  about  the  connection.  The 

following  flags  exist: 

C  The  connection  is  half-closed  (one  of  its  I/O  channels  has  been  closed  and 
the  other  remains  open). 

F  The  connection  is  turned  "ofT’  as  far  as  die  intermpt  side  of  die  NCR  is 
concerned.  No  packets  will  be  received  or  transmitted. 

1  The  connection  has  an  input  buffer  for  stream  (non-packet)  input. 

O  The  connection  has  an  output  buffer  for  stream  (non-packet)  output. 

S  An  STS  packet  needs  to  be  sent. 

T  The  connection  is  connected  to  a  STY.  In  other  words  it  is  an  incoming 

Telnet  or  Supdup  connection  and  the  system  is  providing  the  data  transfer 

between  the  connection  and  the  pseudo  terminal. 

The  ;CHASTA  command  is  a  long-winded  version  of  the  above.  It  prinLs  several  lines  of 
infonnation  about  each  connection  duit  exists,  including  the  number  of  the  next  packet  to  be 
given  to  the  user,  die  number  of  the  next  packet  to  be  output  by  die  user,  aiul  die  number  of 
the  last  packet  acknowledged  in  each  direction. 

Ihc  :CHARFC  command,  given  a  host  name  and  a  contact  name  in  the  command  line,  will 

open  a  connection  and  print  whatever  comes  back  (refusal,  simple  tiansaction,  or  any  datii  that 

emerge  from  a  stream  connection).  The  contact  n.ime  may  of  course  be  followed  by  a  space  and 
arguments.  This  command  can  be  useful  in  connection  with  the  STATUS  protrx'ol,  to  sec  if  a 
host  is  up  (it  will  print  its  name  followed  by  some  gavb.ige  characters),  and  in  connection  with 
the  PULSAR  protocol,  to  turn  puls, us  on  and  olf. 

The  :CHATST  command  provides  a  v.uicty  of  simple  (  'haosnet  m.inipulating  commands.  Run 
it  and  type  ?  for  a  list  of  the  comm. aids.  Ihc  II  tliost.it)  comm.iiid  m.iy  be  the  nuist  useful;  it 
uses  the  STATUS  protocol  to  get  nicteiing  miorm.uion  from  a  host  .ind  prints  it  nicely. 

The  :UOST  command  given  the  n.ime  of  a  host  in  lhi\coinni,ind  line,  looks  np  til. it  host  in 
the  •.yslem  host  i  ihk-  .nul  prints  .\h,a  i-.  I  nov.n  .ihont  it.  ii\!nilini!  its  mimeiie  , id. loos.  I  his 
works  fi'r  hosts  oii  ill  iielwoiks.  Ih.'  .<  IIAIAU  lomni.nul  piibcs  .1  l.ihle  of  all  the  hosts  on 
Chaosnet.  \ 
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8.3  Server  Programs 

When  an  RFC  is  received  for  a  contact  name  for  which  there  is  no  outstanding  LSN,  the 
RFC  packet  is  saved  on  a  pcnding-RFC  queue  and  a  new  process  is  created  and  made  to  run  the 
program  in  the  file  SYSiATSIGN  CHAOS.  Ilns  program  uses  the  CHAOSQ  system  call  to  find 
out  the  contact  name  of  the  RFC.  The  contact  name  mime  is  truncated  to  six  characters  if  it  is 
longer.  If  a  file  named  DSr<:DEVICE;CHAOS  name  exists,  that  file  contains  the  desired  server 
program;  it  is  loaded  into  the  server  process.  When  tlic  server  process  is  started,  register  0 
contains  the  contact  name  in  sixbit  and  channel  1  is  still  open  to  the  program  file.  The  server 
program  must  do  a  listen  for  its  contact  name,  open  the  connection,  log  in,  and  so  forth. 

llius  a  server  for  a  new  prot(x:ol  can  be  added  simply  by  putting  a  link  on  the  DEVICE 
directory.  This  directory  is  also  used  for  Arpanet  servers  and  for  I  TS  I/O  device  servers. 

If  no  file  is  found,  a  file  named  DSK:DEVICE:CHAOS  DFAULT  is  loaded  if  it  exists.  If  it 
docs  not  exist  cither  (which  is  normally  the  case)  the  RFC  is  ignored  and  the  server  process  kills 
itself.  After  a  while  the  system  will  refuse  the  RFC  by  sending  back  a  CI.S  unless  someone 
comes  along  and  listens  for  it 

8.4  Subroutine  Packages 

llie  file  SYSTEM:CHSDEF  >  can  be  .INSRT’cd  into  a  Midas  program  to  define  symbols  for 
tlie  format  of  a  packet,  die  packet  opcodes,  and  the  states  of  a  connection.  The  symbol  prefixes 
arc  %CO  for  opcodes,  %CS  for  states,  $CPK  for  packet-fonnat  byte-pointers,  and  %CP  for 
packet-format  values. 

'fhe  file  SYSENG;NETWRK  >  can  be  .INSRT’cd  into  a  Midas  program  to  provide  a  library  of 
subroutines  for  opening  connections,  listening  for  requests  for  connection,  analyzing  network 
errors  and  printing  useful  messages  to  the  user,  and  accessing  the  host-name  table 
(SYSBIN;HOSTS2).  All  system  programs  that  use  the  Chaosnet  do  so  with  the  aid  of  these 
ciibroutincs.  NETWRK  .supports  both  Chaosnet  and  Arpanet.  Dwumenuition  is  provided  in 
omments  at  the  beginning  of  the  file. 


l>SK;MtH)N;AMUi:R  107 


15  JIIN-Sl 


Chaosnet 


43 


Che  I OPS-20/TI{N!-X  Implementation 


9.  The  TOPS-20/TENEX  Implementation 

A  Chaosnet  connection  is  represented  by  a  JFN  obtained  from  die  CHA:  device.  The 
standard  I/O  operations  can  be  performed  on  such  a  JFN,  in  wliich  case  the  system  will  open  a 
Chaosnet  stream  connection  and  transfer  8-bit  bytes  in  both  directions.  When  a  Chaosnet 
connection  is  used  in  this  way.  it  is  compatible  with  the  rest  of  the  rOPS-20  file  and  I/O  system. 

Alternatively,  special  operations  can  be  used  to  send  and  receive  packets  and  do  other 
Chaosnet-specific  operations  on  a  Chaosnet  JFN.  fhese  arc  described  below. 

For  more  information,  see  [CFR]. 


9.1  Opening  Connections 

A  (potential)  Chaosnet  connection  is  represented  by  a  JFN.  When  the  JFN  is  opened,  an 
actual  Chaosnet  connection  is  created.  The  GTJFN  syntax  is  as  follows: 

The  device  name  is  CHA:.  The  filename  is  the  symbolic  name  or  octal  number  of  the  host  at 

the  other  end  of  the  connection,  or  a  null  string  if  it  is  desired  to  listen  for  an  incoming  Request 

For  Connection  rather  than  initiating  a  connection.  The  extension  (filctypc)  is  normally  the 
contact  name;  some  special  eases  arc  described  below.  Use  of  *  niuncs  and  JFN  stepping  is  not 
permitted.  I'he  directory,  generation  (version)  number,  and  .semicolon  attributes  arc  ignored  if 
present. 

When  the  JFN  is  opened  (with  OPENF),  nomially  the  system  will  wait  for  the  connection  to 
open  up;  a  user  connection  (nonblank  filename)  will  wait  for  a  response  to  be  returned  to  its 
RFC,  and  a  server  connection  (blank  filename)  will  wait  for  an  RFC  to  come  in  to  its  contact 
name.  If  an  RFC  is  refused  or  the  foreign  host  is  not  up,  OPENF  will  return  an  error.  If  data 

mode  6  or  7  is  used  with  OPENF,  it  will  return  immediately,  without  waiting  for  ilic  connection 

to  open.  This  is  useful  if  you  want  to  open  several  Chaosnet  connections  simultaneously,  or  if 
you  want  to  determine  the  reason  for  failure  if  the  connection  does  not  open;  if  die  normal  data 
mode  0  OPENF  fails,  the  operating  system  will  not  let  you  read  the  CLS  packet  nor  do  the 
.MOERR  operation  (described  below). 

'['here  arc  a  number  of  special  eases  in  die  GTJFN  syntax.  If  the  extension  is  a  null  string, 
then  the  contact  name  is  specified  by  OPENF  rather  than  by  GTJFN;  AC3  contains  die  number 
of  characters  in  the  contact  name  in  the  left  half,  and  die  address  of  die  contact  name  in  die 
right  half.  In  listening  mode  (the  filename  is  a  null  siring),  then  if  the  extension  is  also  null,  diis 
JFN  will  listen  to  any  RFC  th.it  is  not  otherwise  serviced.  Privileges  arc  required  and  only  one 
job  at  a  time  can  do  this.  This  mechanism  is  used  by  a  system  server  process.  If  the  filename  is 
null  and  the  extension  is  a  hyphen,  the  JFN  is  put  in  a  special  mode  for  simple  transactions; 
packet-level  I/O  may  be  used  to  transmit  any  number  of  RFCs  and  receive  any  response  packets 
(ANS,  FWI),  I.OS,  or  CI  S). 

When  a  JFN  is  ilo:,ed  with  CLOSE,  if  it  has  an  open  comueiioii  (he  end  ofdata  prol(x.ol  is 
used  (an  lOI  p.ickcl  is  transmitted  and  its  aeknowiodgement  is  .iwailed),  and  tlioii  a  (  I  S  packet 
is  li.iii  iiiiili  d.  (Ilii>  is  not  loniplelely  implemented  .et;  iiiirciitly  no  1  OF'  Is  sent,  ,iiul  .MOEOF 
(s'a-  b.'Inw)  mill  he  iiseil.)  II  ihe  ,11  M  is  in  die  I'll '  F’.ei.ei\ed  si.ile,  die  Kit  is  oliised  bv 
seiidiiii’  a  C  l  S. 
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9.2  Stream  Input  and  Output 

llic  normal  I/O  JSYScs  (BIN,  BOUT,  SIN,  SOUT)  work  on  Chaosnet  JFNs.  When  the 
connection  was  created  by  listening,  doing  I/O  to  it  automatically  accepts  it  first  (sending  an 
OPN).  'Hie  input  and  output  data  arc  transmitted  as  8-bit  bytes  in  standard  data  packets  (opcode 
200).  On  input,  if  an  HOF  packet  is  encountered  the  standard  end-of-file  action  occurs.  If  a  CLS 
or  I, OS  is  encountered,  or  the  connection  is  in  a  bad  state,  an  error  is  signalled.  TTic  message 
from  the  CHS  or  LOS  may  be  picked  up  with  .MOERR  (see  below). 

On  rOPS-20,  but  not  Tcncx,  the  SIBE,  SOBE,  DIBE,  DOBE,  SINR,  and  SOUTR  JSYSes 
may  be  used.  The  latter  two  treat  each  packet  as  a  separate  record. 

The  OPENF  byte  size  may  be  either  7  or  8.  With  a  byte  si/e  of  8,  the  raw  Chaosnet  data 
bytes  are  transmitted.  With  a  byte  size  of  7,  the  system  converts  between  the  ASCII  code  it  uses 
normally  and  the  Lisp  Machine  character  set,  which  is  standard  on  Chaosnet.  (This  is  not  yet 
implemented;  currently  a  byte  size  of  7  will  be  accepted  but  will  behave  the  same  as  8.) 

9.3  Packet  Input  and  Output 

It  is  possible  to  do  packet-level  input  and  output  and  to  deal  directly  with  the  details  of  the 
Chaosnet  prottKOl  by  using  tlie  special  operations  described  in  the  following  section.  Note  that 
stream  I/O  and  packet  I/O  should  not  be  mixed  in  the  same  connection,  unless  you  know  exactly 
what  you  <u'c  doing,  since  you  can  get  your  data  out  of  order. 


9.4  Special  Operations 


GDSTS  returns  device-dependent  status.  AC2  returns  the  state  of  the  connection,  and  AC3 
returns  the  number  of  packet  slots  available  in  the  output  window  in  the  left  half,  and  the 
number  of  available  input  packets  in  the  right  half.  1'he  symbolic  names  for  the  connection  states 
are  as  follows: 


•CSCLS  TTic  connection  is  closed  (or  was  never  opened). 
eSLSN  I  he  connection  is  listening  for  an  RFC. 

.CSRFC  An  RFC  has  been  received  by  a  listening  connection. 
eSRFS  An  RFC  has  been  sent. 

•CSOPN  The  connection  is  open. 

•CSLOS  The  connection  has  been  broken  by  a  LOS  packet. 

•CSINC  The  coiineclion  has  been  Inoken  by  Ineoniplcie  Tiansinission  (no  response  from 

the  other  end  for  a  long  time). 

.eSPRF  Ibis  is  tbc  "peiinarient  RI  C”  stale  which  is  entered  by  GTJFN  with  a  null 

(ilenanic  and  an  extension  of  just  a  hyphen. 


MTOPR  perrorms  a  v.iriely  of  special  operatimts,  with  the  JfN  in  ACl,  one  of  tli>'  following 
loikiioii  inilfs  in  AC?,  and  .in  .ni'iinienl  and/or  lelurn  v.iloe  in  AC3. 

Send  a  p.ieket,  AC3  eonliins  the  address  of  Ihe  first  woiil  of  tlie  packet.  An 
enor  relurn  is  l.iken  if  the  tonneclion  is  in  a  h.id  slate  lor  ihe  kind  of  p.ieket 
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•MOPKR 

■MOOPN 

•MOSND 

■MOEOF 

.MONOP 

•MOERR 


•MOACN 


•MOSWS 

.MORWS 

■MOAWS 

•MOUAC 

.MOFHS 

.MOSIZ 

•MOSRT 


being  transmitted.  'Phis  will  wait  for  space  to  be  available  in  the  window. 

Receive  a  packet.  ACS  contains  the  address  of  a  126- word  buffer  in  which  the 
packet  is  to  be  stored.  'I'his  will  wait  until  an  input  packet  arrives. 

Accept  a  Request  for  Connection.  Error  if  the  connection  is  not  in  the  RFC- 
received  state. 

P'orce  out  any  buffered  stream  output. 

Force  out  any  buffered  stream  output,  then  send  an  EOF  packet. 

Force  out-  any  buffered  stream  output,  tlicn  wait  for  it  to  be  transmitted  and 
acknowledged.  ('Phis  is  not  a  "no  op",  but  .MONOP  is  the  system  standard  name 
for  tliis  operation.) 

Returns  the  error  message  from  a  received  CI.S  or  l.OS  packet.  An  error  is 
signalled  if  no  error  message  is  available.  ACS  is  a  string  pointer  to  where  to  put 
the  error  message:  it  is  updated  to  point  at  the  terminating  null  character  which 
makes  tire  message  an  ASCI/,  string. 

Assigns  PSI  (interrupt)  channels.  I  he  left  half  of  ACS  is  the  channel  number  for 
output  interrupts,  and  die  right  half  is  the  channel  number  for  input  and  state- 
change  interrupts.  Specifying  -1  as  a  channel  number  disables  interrupts.  Output 
interrupts  arc  signalled  when  the  window  is  full  and  then  an  acknowledgement  is 
received  which  makes  some  space  so  tliat  more  packets  may  be  output.  Input 
interrupts  arc  signalled  when  die  state  changes,  and  when  there  arc  no  input 
packets  available  and  then  a  packet  is  received. 

Sets  the  receive  window  si/e  from  AC3. 

Returns  the  receive  window  size  in  the  left  half  of  ACS  and  Ihe  transmit  window 
size  in  the  right  half. 

Returns  the  available  space  in  the  transmit  window  in  ACS. 

Returns  the  number  of  unacknowlcilgcd  output  packets  in  ACS. 

Returns  the  foreign  host  number  in  ACS. 

Returns  the  maximum  packet  si/c  in  bytes  in  ACS.  This  can  be  smaller  than  the 
Chaosnet  standard  (488)  on  machines  encumbered  with  an  RSX2I)F  front  end. 

Sets  the  RFC  timeout  period  in  milliseconds  from  ACS.  fhe  maximum  is  262 
seconds. 


9.5  Utility  Programs 

There  are  two  Chaosnet  utility  programs,  both  named  CHASTA.  One  prints  one  line  for  each 
connection  that  exists,  giving  its  state,  nninher  of  input  and  ouiimt  packets,  who  it  is  connected 
to,  etc.  The  other  prints  the  STATUS  protocol  inform. ilion  for  every  iK'st  on  the  network, 
including  Ihe  host  name,  when  it  w.is  last  up,  .nnl  its  p.ieket  thioiighput  .and  eiior  c(  imis.  I  his 
inform. Ilion  is  niainlamcd  by  a  system  ilaemon  pnicess. 
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9.6  Server  Programs 

When  an  RFC  is  received  for  contacl-name,  if  no  process  is  listening  for  contact-name  and 
the  file  SYSTEM:CHAOS.C£i/i/<Jc/-«flme  (or  DSK:<SYSTEM>CHAOS.co/i/flc/-/ifl/Me  on  Tcncx)  exists, 
the  server  program  contained  in  that  file  is  run.  'ITic  server  program  should  open  CH^\.contact- 
name.  This  is  implemented  by  the  CHARFC  program  which  runs  as  a  daemon  job  and  opens 
CHA:.,  the  magic  name  which  gets  a  copy  of  all  unclaimed  RFCs.  Normally  the  server  program 
is  run  in  a  freshly-created  job.  and  may  log  in  if  it  wishes,  but  if  the  file  is  marked  as  ephemeral 
(the  ":E"  attribute),  it  is  run  in  a  subfork  of  tlic  CHARFC  job.  Hphemcral  servers  should  be 
used  for  protocols  that  don’t  involve  a  long-term  connection. 

The  TELNET  and  SUPDUP  servers  attach  their  Chaosnet  connection  directly  to  an  NVT,  just 
as  the  corresponding  Arpanet  servers  do. 

When  the  system  starts  up.  tlie  file  SYSTEM:HOSTS2.BIN  (or  DSK:<SYSTEM>HOSTS2.BIN 
on  Tencx)  is  read  in  and  used  to  initialize  the  host  name  uiblc  inside  the  system  used  by  GTJFN. 
This  is  the  lT'S/i’OPS-20/ WAIT'S  standard  multi-network  host  table. 
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10.  The  Lisp  Machine  Implementation 

Lisp  Machine  Chaosnet  support  consists  of  a  set  of  Lisp  functions  and  data-structurc 
definitions  in  the  chaos:  package.  There  are  three  important  data  structures.  A  conn  represents 
a  connection.  A  pkt  represents  a  packet.  A  stream  is  a  standard  I/O  stream  which  transmits  to 
and  receives  from  a  connection.  The  details  of  these  data  structures  arc  described  later. 

rhcrc  arc  two  processes  which  belong  to  the  Chaosnet  NCP.  ITic  receiver  process  looks  at 
packets  as  they  arrive  from  tlic  network.  Control  packets  arc  processed  immediately.  Data  packets 
arc  put  on  the  input  packet  queue  of  the  connection  to  which  they  arc  directed.  The  background 
prtKcss  wakes  up  periodically  to  do  retransmission,  probing,  and  certain  "background  tasks"  such 
as  starting  up  a  server  when  an  RFC  arrives  and  prticcssing  "connection  interrupts"  (described 
below). 

10.1  Opening  and  Closing  Connections 

10.1. 1  User-Side 

chaos: connect  hosl  contact-name  &optional  window-size  timeout 

Opens  a  stream  connection,  and  returns  a  conn  if  it  succeeds  or  a  string  giving  the 
reason  for  faihirc,  hast  may  be  a  tuimbcr  or  the  name  of  a  known  host.  ca/iMct-name  is 
a  string  containing  the  contact  name  and  any  additional  arguments  to  go  in  die  RFC 
packet.  If  window-size  is  not  specified  it  defaults  to  13.  If  timeout  is  not  specified  it 
defaults  to  600  (ten  seconds). 

chaos: simple  host  contact- name  Aoptional  timeout 

Taking  arguments  similar  to  those  of  chaos:connect,  this  performs  the  user  side  of  a 
simple-transaction.  The  returned  value  is  either  an  ANS  packet  or  a  string  containing  a 
failure  message.  Ihe  ANS  packet  should  be  disposed  of  (using  chaos:return- pkt,  sec 
below)  when  you  arc  done  with  it. 

chaos : remove-conn  conn 

Makes  conn  null  and  void.  It  becomes  inactive,  all  its  bulfcrcd  packets  arc  freed,  and  the 
corresponding  Chaosnet  connection  (if  any)  goes  away. 

chaos: close  conn  &optional  reason 

Closes  and  removes  die  connection.  If  it  is  open,  a  Cl  S  packet  is  sent  containing  the 
string  reason.  Don’t  use  tlii.s  to  reject  RFC's;  use  chaos:reject  for  that. 

chaos  :open-fore1gn-connect1on  host  index  Aoptional  pki-allocation  distinguished-port 

Creates  a  conn  which  may  be  used  to  transmit  and  receive  foreign  protocols  encapsulated 
in  I  INC  p;i(  kets.  host  and  inde.s  arc  the  destination  addiess  (iir  p.iekets  sent  with 
r.haosisond  unc  pkt.  pki  iilliHiiiion  is  the  "window  si/e",  i.e,  the  m.ixinuim  numlier  of 
input  p.iekels  whiili  m.iy  be  bulb  o  il.  It  defaiills  to  |0,  It  il:\iii;r.tn\itid  pmt  is  supplied, 
the  l(K.il  indi'x  is  set  to  it.  this  is  ne<ess.iry  h'l  piotmols  whiili  deline  the  meiniiij'S  ol' 
p.iitieidar  index  numbers 
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10.1.2  Server-Side 

chaos: listen  contact-name  &optional  window-size  wait-for-rfe 

Waits  for  an  RFC  For  the  specified  contact  name  to  arrive,  then  returns  a  conn  which 
will  be  in  the  RFC  Received  state.  If  window-size  is  not  specified  it  defaults  to  -13.  If 
waii-for^rfe  is  specified  as  nil  (it  defaults  to  t)  tlicn  the  conn  will  be  returned  immediately 
without  waiting  for  an  RFC  to  arrive. 

chaos :server-a1 1st  Variable 

Contains  an  entry  for  each  server  which  always  exists.  When  an  RFC  arrives  for  one  of 
these  servers,  the  specified  foim  is  evaluated  in  tlie  background  process;  typically  it 
creates  a  pnx:css  which  will  then  do  a  chaos:listen.  Use  the  add -initialization  function 
to  add  entries  to  this  list. 

chaos: accept  conn 

conn  must  be  in  the  RFC  Received  state.  An  ORN  packet  will  be  transmitted  and  conn 
will  enter  the  Open  state.  If  the  RFC  packet  has  not  already  been  read  with  chaosiget- 
next-pkt,  it  is  discarded.  You  should  read  it  before  accepting  if  it  contains  arguments  in 
addition  to  the  contact  name. 

chaos: reject  conn  reason 

conn  must  be  in  the  RFC  Received  state.  A  CLS  packet  containing  the  string  reason  will 
be  sent  and  conn  will  be  removed. 

chaos: answer-string  conn  string 

conn  must  be  in  the  RFC  Received  state.  An  ANS  packet  containing  tlie  string  string  will 
be  sent  and  conn  will  be  removed. 

chaos: answer  conn  pkt 

conn  must  be  in  the  RFC  Received  state,  pkt  is  transmitted  as  an  ANS  packet  and  conn 
is  removed.  Use  this  function  when  tlie  answer  is  some  binary  data  rather  titan  a  text 
string. 

chaos:fast-answer-str1ng  contact-name  string 

If  a  pending  RFC  exists  to  contact-name,  an  ANS  containing  string  is  sent  in  response  to 
it  and  t  is  returned.  Otherwise  nil  is  returned.  I’his  function  involves  the  minimum 
possible  overhead.  No  conn  is  created. 


IU.2  Connection  States 
chaos: state  conn 

Returns  the  current  state  of  the  connection,  as  one  of  Uie  following  symbols: 

chaos. inactive -state  A  conn  which  docs  not  correspond  to  any  Chaosnet 

connection. 

chao:5:open  -state  An  open  connection. 

ch.\05:rfc- sent  state  An  Rl  ('  has  been  transmitted  and  no  response  has  yet 

been  received. 
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chaos:answered-state 
chaosxis  -  received  -  state 
chaos:  los  -  received  -  state 
chaos:host -down -state 

chaos:listening -state 

chaosirf c  -  received  -  state 

chaos:foreign -state 


All  ANS  has  been  received. 

A  CI.S  has  been  received. 

A  I.OS  has  been  received. 

The  connection  is  in  the  Incomplete  Transmission  state; 
communications  wiili  tlic  foreign  host  have  broken  down. 

A  I.SN  has  been  "transmitted"  and  the  connection  is 
awaiting  an  KKC. 

An  Rl'C  has  been  received  while  listening  and  has  not  yet 
been  responded  to. 

'I'hc  connection  is  being  used  witli  a  foreign  protocol 
encapsulated  in  UNC  packets. 


chaos: wait  conn  state  timeout  &optional  whostate 

Waits  until  the  state  of  conn  is  not  die  symbol  state,  or  until  timeout  60ths  of  a  second 
have  elapsed.  If  the  timeout  (x:curs,  nil  is  returned;  otherwise  t  is  returned,  whostate  is 
the  process  state  to  put  in  the  who-Iinc;  it  defaults  to  "net  wait". 


10.3  Stream  Input  and  Output 
chaos: stream  conn 

Creates  a  bidirectional  stream  which  accesses  conn,  which  should  be  open  as  a  stream 

connection,  as  8-bit  bytes.  In  addition  to  the  usual  I/O  operations,  die  following  special 

operations  arc  supported: 

:force-output  Any  buffered  output  is  transmitted.  Normally  output  is  accumulated  until 
a  full  packet’s  worth  of  bytes  arc  available,  so  diat  maximum-size  packets 
arc  transmitted. 

:finish  Waits  until  cither  all  packets  have  been  sent  and  acknowledged,  or  the 

connection  ceases  to  be  open.  IF  successful,  returns  t;  if  the  connection 
goes  into  a  bad  state,  returns  nil. 

:eof  I-orccs  out  any  buffered  output,  sends  an  liOP'  packet,  and  docs  a  :finish. 

:clear-eof  Allows  you  to  read  past  an  HOF  packet  on  input,  l-iaeh  :tyi  will  return  nil 

or  signal  the  specified  eof  error  undl  a  :clear-eof  is  done. 

:close  Send  a  CHS  packet  and  remove  die  connection. 

10.4  l*iU'ko(  liijiut  anil  Output 

Input  and  output  on  a  Ch.aosnci  connedion  can  be  done  at  die  whole-packet  level,  using  the 
functions  in  this  section.  A  packet  is  lepiesemed  by  a  pkt  data  structure.  Allocation  of  pKts  is 
Kinlrollcd  bv  the  system;  e.ich  pkt  that  it  ejves  yon  must  be  jiivoii  back.  Ilicie  are  functions  to 
convert  between  (jkts  and  strings.  A  pkt  is  an  nit  161)  array  coni, lining  the  p.ickei  hc.idei  and 
data;  tlie  olinorsiiinsl  data  wnttl  in  jikt  ib  element  of  the  air.iy  is  the  lirst  Ih-bil  d.ita  word.  The 
leader  of  a  [ikt  conl.iins  a  number  of  fields  leed  by  die  system. 


l):,k;MtK)N;AMIU  K  107 


l.SJUN-81 


Packet  Input  and  Output 


Chaosnet 


chaos :pkt-opcode  pki 

Accessor  for  the  opcode  field  of  pkl'%  header.  For  each  standard  opcode  a  symbol  exists 
in  the  chaos:  package,  consisting  of  the  standard  3-lcttcr  code  and  a  suffix  of  "-op", 
chaos:rfc-op  for  example.  Ilie  value  of  the  symbol  is  the  numeric  opcode. 

chaos :pkt-nbytas  pkt 

Accessor  for  the  number-of-data-bytes  field  of  pki's  lieader. 

chaos :pkt-str1ng  pki 

An  indirect  array  which  is  the  data  field  of  pkt  as  a  string  of  8-bit  bytes.  I’hc  length  of 
this  string  is  equal  to  (chaos;pkt-nbytes  pkt). 

chaos  :set-pkt-str1ng  pkt  &rcst  strings 

Copies  the  strings  into  the  data  field  of  pkt,  concatenating  them,  and  sets  (chaos:pkt- 
nbytes  pkt)  accordingly. 

chaos :get-pkt 

Allocates  a  pkt  for  use  by  the  user. 

chaos ; return-pkt  pkt 

Deallocates  a  pkt. 

chaos ;  send-pkt  conn  pkt  Aoptional  (opco(/echaos:dat-op) 

Transmits  pkt  on  conn,  pkt  should  have  been  allocated  with  chaos:get-pkt  and  then  had 
its  data  field  and  n-bytes  filled  in.  opcode  must  be  a  data  opcode  (200  or  more)  or  HOF. 
An  error  is  signalled,  with  condition  chaos:not-open-state.  if  conn  is  not  open. 

chaos :send-8tr1ng  conn  &rcst  strings 

Sends  a  data  packet  containing  die  concatenation  of  strings  as  its  data. 

chaos :  send-unc-pkt  conn  pkt  Aoptional  pkl-nunibcr  ack-number 

I'ransinits  pkt,  an  UNC  packet,  on  conn.  The  opcode,  packet  number,  and  acknowledge 
number  fields  in  die  packet  header  arc  filled  in  (the  latter  two  only  if  die  optional 
arguments  arc  supplied). 

chaos :niay-tPansin1t  conn 

A  predicate  which  returns  t  if  there  is  any  space  in  the  window. 

chaos:f1n1sh  conn  Auptional  (tv/zoiA/rc "Net Finish") 

Waits  until  cither  all  packets  have  been  sent  and  acknowledged,  or  the  connection  ceases 
to  he  open,  if  successful,  returns  t;  if  the  connection  goes  into  a  bad  state,  returns  nil. 
nliosiate  is  the  process  state  to  display  in  the  who  line  while  w.iiling. 

chaos :  got-noxt-pkt  conn  Azzptional  (no-liiini;-pr}i\) 

Kelunis  the  next  input  packet  from  coni'.  When  you  arc  done  with  the  packet  you  must 
give  it  hack  to  the  system  with  chaosi.'chirn  pkt.  Ihis  can  leitun  an  UIX',  I'l  S,  or 
ANS  packet,  in  addition  to  data,  UNC.  (.'■  I•0|■.  If  no  luing-i)  is  t,  oil  will  lie  leturneil 
if  there  .iic  no  jiackcts  available  or  the  loiaici  ijon  is  in  a  had  state.  Oiheiwi  .e  an  error 
will  be  sign. tiled  il  the  lonneclion  is  in  .1  bail  slate,  with  condition  n.inic  di  in'rhost- 
down,  chiiosilos-  rrceivt'd  stale,  or  channtro.nl  on  i:losod  connoc.lion.  If  no  packets 
ate  available  and  no-hong  p  is  nil,  chaosiget  in’xl  (rkt  will  wait  Itn  packets  to  come  in 
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or  the  state  to  change.  'I'he  process  state  in  the  who-line  is  "NETI”. 

chaos :data-avai1 able  conn 

A  predicate  which  returns  t  if  there  any  input  packets  available  from  conn. 

10.5  Connection  Interrupts 

chaos ; 1nterrupt-funct1on  conn 

This  attribute  of  a  conn  is  a  function  to  be  called  in  the  background  prcKCss  when  certain 
events  occur  on  tliis  connection.  Normally  this  is  nil,  which  means  not  to  call  any 
function,  but  you  can  use  self  to  store  a  function  here.  Since  tltc  function  is  called  in 
the  Chaosnet  background  prixtcss,  it  should  not  do  any  operations  that  might  have  to  wait 
for  the  network,  since  that  could  permanently  hang  the  background  process. 

The  fiinction’s  first  argument  is  one  of  the  following  symbols,  giving  the  reason  for  the 
''interrupt",  '('he  function’s  second  argument  is  conn.  Additional  arguments  may  be 
present  depending  on  die  reason.  The  possible  reasons  are: 

■input  A  packet  has  arrived  for  the  connection  when  it  had  no  input  packets 

queued.  It  is  now  possible  to  do  chaos:get-next-pkt  without  having  to 
wait.  There  arc  no  additional  arguments. 

:output  An  acknowledgement  has  arrived  for  the  connection  and  made  space  in 

the  window  when  formerly  it  wa'^  full.  Additional  output  packets  may 
now  be  transmitted  with  chaos:send-pkt  without  having  to  wait,  'Hierc 
arc  no  additional  arguments. 

:change- of -state 

Ihc  state  of  the  connection  has  changed,  'flic  third  argument  to  die 
function  is  the  symbol  for  the  new  state. 

chaos : read-pkts  conn 

Some  interiupt  functions  will  want  to  look  at  die  queued  input  packets  of  a  connection 
when  dicy  get  a  :input  internipt.  chaos:read-pkts  returns  the  first  packet  available  for 
reading.  Successive  packets  can  be  found  by  following  chaos:pkt-link. 

chaos:pkt-l1nk  pkt 

l.ists  of  p.iekcts  in  the  NCP  arc  threaded  together  by  storing  each  packet  in  the 
chaos:pkt  link  of  its  predecessor.  I'he  list  is  terminated  with  nil. 


10.6  Inrorinatioii  tiiiil  Control 
chaos :host  data  &o|nional  lio.u 

linsl  may  he  a  number  or  .i  known  host  ii.inie.  and  defaults  to  the  local  host,  I  wo  v.ilties 
are  letunierl.  I  he  first  value  is  the  host  name  aiul  the  serond  is  the  host  nuinlier.  If  the 
host  is  a  iiumhi’i  not  in  Ihe  l.ible,  it  is  asked  its  name  using  the  STATU!')  innioLol;  if  no 
lesponse  is  lereiwd  the  ii.aine  "Uiil.iiowii"  is  returned. 
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ho  s  tat  &resc  hosts 

Interrogates  titc  specified  hosts,  or  all  known  hosts  if  none  are  specified,  with  the 
STATUS  protocol  and  prints  the  results  in  columns  ns  a  table. 

chaos: print- conn  conn  dcoptional  (shorn) 

Prints  everything  the  system  knows  about  the  connection.  If  short  is  nil  it  also  prints 
everything  the  system  knows  about  each  queued  input  and  output  packet  on  the 
connection. 

chaos  :pr1nt-pkt  pkt  &optional  (s/ior/nil) 

Prints  everything  the  system  knows  about  the  packet,  except  its  data  field.  If  short  is  t, 
only  the  first  line  of  the  information  is  printed. 

chaos:pr1nt-a11-pkt8  pkt  &optional  (shortt) 

Calls  chaos:print-pkt  on  pkt  and  all  packets  on  the  threaded  list  emanating  from  it 

chaos: status 

Prints  the  hardware  status. 

chaos: reset 

Resets  tlie  hardware  and  software  and  turns  off  the  network. 

chaos :assure-enab1ed 

Turns  on  the  network  if  it  is  not  already  on.  It  is  nomaliy  always  on  unless  you  call  one 
of  these  fimetions. 


chaos:enable 

Resets  the  hardware  and  turns  on  the  network. 

chaos:d1sab1s 

Resets  the  hardware  and  turns  olF  the  network. 
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11.  The  VAX/ VMS  liiiplcmentation 


This  describes  the  interface  to  Chaosnet  through  the  routines  in  the  "CHAOS.f332"  I)I.ISS-32 
subroutine  package.  Definitions  of  suindard  values  are  in  "NCPDIil'S.R32".  'I  hough  it  is  possible 
to  interface  to  the  NCT  at  the  VMS  I/O  level,  it  is  not  recommended  practice.  All  references  to 
Chaosnet  in  this  text  arc  w'ith  respect  to  die  subroutine  package,  and  not  VMS  QIO’s. 

A  Chaosnet  connection  is  represented  by  a  one  longwoid  "channel  number",  which  has  no 
direct  relationship  to  a  VMS  channel  number.  Ilow'cver.  for  every  Chaosnet  channel  currently 
allocated,  there  is  an  associated  VMS  channel  maintained  by  the  subroutine  package. 

All  of  the  routines  described  below  arc  declared  "global". 

1  ] .  1  Opening  and  Closing 
parse_host  (host,  rei-host-num) 

Parses  the  string  pointed  to  by  liosi  (which  points  to  a  standard  VMS  string  descriptor), 
and  stores  the  resulting  host  number  in  the  word  pointed  to  by  ret- host- num.  Returns  a 
status  code, 

chaos_rf  c  (rci-chan,  host,  contact-name,  wait-time) 

Opens  a  new  Chaosnet  channel  and  sends  an  RP'C.  ret-chan  is  a  longword  to  receive  the 
channel  number,  host  is  a  siring  acceptable  to  parse_host.  conlact-numc  is  a  pointer  to  a 
string  descriptor,  yvait-time  is  either  zero,  which  means  to  wait  indclinitely  for  a  response 
to  the  RPC,  or  a  pointer  to  a  qiiadword  bl(x;k  acceptable  to  die  $SETIMR  system  service. 
A  status  code  is  returned,  which  will  be  SS$_TIMEOUT  if  the  routine  times  out. 

chaos_lsn  (ret-chan,  contact-name,  wait-time) 

l.ikc  chaos_rfc,  but  "sends"  a  l.SN  instead  of  an  RP'C.  No  host  is  specified. 

chaos_accept  (chan,  window,  rfc-arg.  rel-rfc-arg-size) 

Accepts  an  incoming  RFC.  riic  connection  must  be  in  RFC- received  state,  window  is  the 
window  size,  rji-arg  is  an  optional  string  descriptor  which  receives  die  argument  to  the 
RFC.  rci-rfc-arg-sizc  is  also  optional,  and  gets  the  argument’s  length. 

Chaos.ans  (chan,  data,  wait-time) 

Sends  an  ANS  packet  to  the  Chaosnet  channel,  data  points  to  a  string  descriptor,  wait- 
time  is  ignored.  A  status  code  is  returned,  and  if  tin  error  occurs,  die  channel  is 
dcassigned. 

chaos^close  (chan,  reason) 

Closes  the  connection,  and  deassigns  the  channel,  reason  is  a  pointer  to  ti  string 
dcM  iipior  of  a  string  to  be  included  in  the  C'F.S  packet. 
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chaot.assign  (rei-chan) 

Assigns  a  Chaosnet  channel,  and  stores  it  in  the  longword  pointed  to  by  rei-chan.  This 
routine  allocates  a  VMS  channel.  A  status  code  is  returned. 

chaos.deassign  (chan) 

Given  a  Chaosnet  channel  previously  assigned  by  chaos.assign,  deassigns  it  and  the 
associated  VMS  channel. 

11.2  Stream  Input  and  Output 

chaos_in_chaP  (cfm,  ret-char,  limeoul) 

Returns  the  next  character  from  the  channel  in  the  longword  pointed  to  by  rehchar. 
Waits  until  a  character  is  available  or  until  timeout,  whichever  comes  first.  A  status  code 
is  returned. 

chaos_out_char  (chan,  char) 

Outputs  one  character.  Characters  arc  buffered  until  a  packet  fills  up  or  until  the  output 
is  forced  out  by  chaos_force_out.  A  status  code  is  returned. 

chaos.sout  (chan,  string) 

I. ike  repeated  calls  to  chaos.out_char:  sends  string  from  string  descriptor  pointed  to  by 
string. 

chaos_fopce_out  (chan) 

If  doing  serial  output,  and  a  partial  packet  is  buffered,  force  it  to  be  sent 
chaos^flnlsh  (chan) 

Does  a  chaos_force_out,  then  waits  for  all  packets  to  be  acknowledged  by  tlic  foreign 
end. 

chaos_eof  (chan) 

Sends  an  KOF  packet  after  forcing  out  any  buffered  output 

1 1.3  Packet  Input  and  Output 

anocato..pkt  (size.  chan,  rcl-pkt) 

Allocates  a  p.ick('t  suitable  for  chaos_in_pkt  and  chaos_out_pkt.  'Hie  packet  can  hold 
up  to  size  bytes  of  data;  the  luiinber  of  bytes  field  in  the  pai.kct's  header  is  filled  in  (iuiii 
size,  rvt-pkt  points  to  a  longword  to  receive  a  pointer  to  the  packet.  A  status  code  is 
returned. 

doa11ocato..pkt  (pkt) 

F.cturns  a  previously  allocated  packet  to  die  free  pool.  A  packet  may  bo  reused,  since  the 
I/O  routines  do  not  dcalltKafe  them,  as  long  .is  the  I/O  is  being  done  synchronously. 
Returns  a  status  code. 


1  iSKiMOON;  Wllfl.R  10/ 


I.V.UIN-N1 


Cliaosnct 


55 


Checking  the  State 


Chaos.out.pkt  (chan.  pkl.  efn,  astaJr.  astprm) 

Outputs  pkl  to  chan,  waiting  if  there  is  no  window  room  available,  efn  is  the  event 
channel  to  use  for  waiting,  astadr  and  asipnn  are  as  for  VMS  system  services;  an  AST 
address  and  parameter,  respectively,  that  get  signalled  when  the  packet  is  read  by  the 
NCP.  chaos_out_pkt  returns  as  soon  as  there  is  space  in  the  window,  witliout  waiting 
for  tlic  NCP  to  finish  transmitting  the  packet. 

cha08_1  n_pkt  (chan.  efn.  pkl,  astadr.  asipnn) 

Reads  the  next  input  packet,  whatever  opcode  it  may  be,  from  the  connection,  waiting 
indefinitely  if  llierc  arc  no  input  packets,  efn  is  the  event  channel  to  wait  on,  and  astadr 
and  astprm  arc  for  an  AST  to  be  delivered  when  the  read  completes.  chaos_in_pkt  docs 
not  return  until  the  read  completes.  A  status  code  is  returned. 

11. 4  Checking  the  State 

chaos_xm1t_rooin  (chan,  wait) 

Returns  SS$_NORMAL  if  there  is  room  left  in  the  transmit  window.  Returns  an  error  if 
the  connection  went  into  a  bad  stale.  If  wail  is  uiic,  and  there  is  no  room  left,  then 
chaos_xmit_room  waits  until  room  is  available.  If  there  is  no  room  left  and  wait  is  false, 
it  returns  SS$_EXQLJOTA. 

chaos.state  (chan) 

Updates  die  state  of  tJte  Chaosnet  channel  via  a  request  to  the  NCP.  Returns  a  status 
code.  To  check  die  state  of  the  connection,  first  call  this  routine  then  look  at  chan.state 
in  the  channel  block  described  below. 

chaos_wa1t  (chan,  old-state,  timeout) 

Waits  until  tlie  channel  goes  out  of  the  specified  state  or  until  timeout  occurs.  Timeout  is 
either  zero  (no  timeout)  or  a  pointer  to  a  quadword  block  acceptable  to  $SETIMR.  A 
status  code  is  returned. 

Chaos_wa1  t_ti  1  (chan,  state,  timeout) 

Waits  until  the  channel  goes  into  the  specified  state  or  until  timeout  occurs.  Timeout  is 
cither  zero  (no  timeout)  or  a  pointer  to  a  quadword  block  acceptable  to  $SETIMR.  A 
status  code  is  returned. 

'Ihc  channel  number  is  used  as  an  index  into  the  global  blockvcctor  channel,  defined  in  the 
"CHAOS. 11.12"  file.  Since  HI.ISS-32  docs  not  allow  the  field  definitions  to  be  global,  they  should 
be  copieil  into  any  program  that  needs  to  look  inside  the  channel  blockvcctor.  Ihc  most  useful 
fields  arc 

chan_state  One  of  the  state  codes  defined  below. 
chan_sla_lxw  The  window  si/c  in  the  ti.msmit  direction. 

chan_sta_rxw  The  window  si/c  in  the  receive  direction. 

chan..sta,Txwa  I  be  numher  of  packet  slots  available  in  the  transmit  wimlow. 

chan_cla.,rxav  I  he  inimhcr  of  input  p.ickets  available. 
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The  states  arc  as  follows; 

conn_st_closed  (0)  Connection  closed  by  a  CLS  packet. 

conn_st_rfcrcv(1)  RFC  received  by  listening  connection. 

conn_st_rfcsnt  (2)  RFC  sent,  no  response  yet. 

conn_st_open  (3)  Connection  open. 

conn_st_los  (4)  Connection  broken  by  a  I.OS  packet. 

conn_st_incom  (5)  Incomplete  transmission  (no  response  from  foreign  host). 

conn_st_new  (6)  Connection  newly  allocated. 

conn_st_lsn  (7)  l.istening  for  an  incoming  RFC. 

conn_st_full  (%0'400')  Ihis  bit  is  set  when  the  transmit  window  is  Rill.  Usually,  the 

remainder  of  the  state  will  be  conn_st_open. 
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12.  The  Unix  Implementation 

The  Unix  implementation  of  Chaosnet  works  on  both  ptlpll  Unix  and  VAX  Unix. 

The  network  may  be  accessed  in  four  dilTercnt  ways.  A  Chaosnet  stream  connection  may  be 
opened  to  a  host  and  a  contact  name,  and  then  standard  Unix  I/O  may  be  done  over  tlie 
connection.  A  Chaosnet  connection  may  be  accessed  at  tlie  packet  level  {howeve^  tliis  is  not  yet 
implemented).  A  Chaosnet  stream  connection  may  be  made  into  a  Unix  tty;  this  is  how  the 
TELNET  server  works.  A  subtree  of  one  Unix  host’s  file  system  may  be  mapped  into  anotlier 
Unix  host’s  file  system,  with  the  intermediate  Chaosnet  invisible  to  programs  operating  on  the 
remote  files. 

You  get  access  to  Chaosnet  by  opening  a  file  patlinamc  which  includes  a  special  file  whose 
major  device  is  Chaosnet.  The  minor  device  number  of  that  special  file,  together  with  its  name 
and  any  additional  pathname  components  after  it,  are  used  to  determine  the  host,  RFC  contact 
name,  and  RFC  arguments.  Remote  file  access  is  unplementcd  by  special  files  which  map  into 
the  desired  host  with  contact  name  ftpread  or  ftpwrite.  The  remaining  pathname  after  tlie  special 
file  is  passed  along  and  used  as  a  pathname  on  the  remote  host. 

The  8-bit  Unix  minor-device  number  is  divided  up  into  several  fields  which  control  details  of 
what  happens  when  you  open  a  Chaosnet  special  file.  I’hc  current  division  is  as  follows: 

bits  6-3  Host  specifier.  Small  numbers  arc  indices  in  a  site-dependent  table  of  hosts  which  arc 
paniculavly  useful  to  connect  to.  'Vhis  is  used  primarily  for  tlie  remote  filc-systcm 
facility.  Otherwise  this  is  one  of: 

015  The  host  number  (in  decimal)  is  read  from  the  name  of  the  special  file. 

016  The  host  number  (in  decimal)  is  read  from  the  next  pathname  component 

after  the  special  file. 

017  Activates  one  of  a  number  of  special  features  selected  by  bits  2-0.  See  below. 

bits  2-0  If  tlie  host  specifier  is  not  017,  this  is  a  contact  name  specifier.  Small  numbers  are 
indices  in  a  site-dependent  table  of  useful  contact  names.  I’liis  is  used  primarily  for 
the  remote  file-system  facility.  Otherwise  this  is  one  of: 

6  Read  the  contact  name  from  the  name  of  the  special  file. 

7  Use  the  rest  of  die  pathname,  aficr  the  special  file,  as  the  contact  name  and 
RFC  arguments. 

When  both  the  host  number  and  the  contact  name  are  read  from  the  pathname,  the 
host  number  is  rc.id  first.  Any  character  other  than  the  digits  0  through  9  serves  to 
separate  them. 

If  the  host  specifier  is  017,  this  is  instead  one  of  the  following: 

0  Pick  up  unmatched  imaiining  Rl  C's.  Only  one  process  at  a  time,  per  system, 
may  open  this  device.  The  ic'cti  opciation  chior.inoxt  (''Ce  below)  is  used 
with  this  device. 

1  I  isten  mode.  The  rest  of  the  p.ilhname.  alter  the  spcti.il  lilc.  is  the  eont.ict 

M.ime  listened  to.  Ibis  will  wait  until  .m  RIC  comes  in  to  that  ii.ilhn.inie.  A 
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typical  patltnamc  would  be  ’Vdev/chlisten/myprotocol". 

2  I.istcn-crror  mode.  Same  as  above,  but  if  there  is  no  pending  RFC  to  the 
contact  munc,  tliis  will  return  an  error  rather  than  waiting  for  one. 

3  Packet  mode.  This  is  not  implemented  yet. 

bit  7  Specifics  that  this  Chaosnet  connection  should  be  wired  to  a  tty. 

When  a  Chaosnet  connection  is  wired  to  a  Unix  tty,  input  data  from  Chaosnet  appear 
as  keyboard  input  characters  on  that  tty.  Output  typed  on  the  tty  goes  out  on 
Chaosnet  as  data.  When  the  tty  is  hung  up  (logged  out),  the  Chaosnet  connection 
will  be  closed.  I/O  operations  done  to  the  Chaosnet  channel  will  be  done  to  the  tty 
instead,  cxeept  for  the  special  ioctl  operations  given  below. 

When  a  connection  has  been  opened,  the  normal  Unix  I/O  operations  may  be  done  on  it.  8- 

bit  bytes  in  standard  data  packets  (opcode  200)  are  used.  If  the  Chaosnet  connection  is  not  open, 

the  I/O  operations  will  return  an  error.  When  the  close  operation  is  performed,  if  the  Chaosnet 
connection  is  open  the  standard  HOF  protocol  will  be  followed  (see  section  4.4,  page  24). 

The  following  operations  arc  supported  for  tlie  ioctl  system  call: 

fionread  Returns  the  total  number  of  data  bytes  in  the  available  input  packets.  This  is  the 
number  of  bytes  which  can  be  read  without  wailing. 

chioeflush  Forces  out  buffered  output.  Normally  .stream  output  is  held  until  a  packet  is  filled 
up  or  2  seconds  have  elapsed. 

chioerread  Returns  data  from  the  RFC  packet.  1'his  is  only  valid  on  a  connection  which  was 
created  by  listening  and  which  has  not  yet  been  read  from.  The  source  host  (2 
bytes)  is  returned,  followed  by  a  null-terminated  eharacter  string  which  is  the 
contact  name  and  any  following  arguments. 

chioernext  This  is  only  valid  on  the  unmatched-RFC  connection,  and  is  the  only  ioctl 
operation  valid  on  it.  This  waits  until  an  unmatched  RFC  is  present,  and  then 
returns  its  contact-name  and  arguments  as  a  null-terminated  string.  I'he  system 
unmatchcd-RI'C  process  uses  this  to  start  up  server  prwesses  as  RFCs  come  in. 
(Currently  this  mechanism  is  used  only  for  the  remote  file-system  servers.) 

chioetty  If  the  Chaosnet  connection  is  open,  and  is  not  already  wired  to  a  tty,  this  creates 
a  new  Unix  tty  and  wires  it  to  the  connection. 
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